Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ee4j-pmc] Jakarta EE / EE4J Technical Vision document

Hi,
I know some of this discussion was started under the "PMC Minutes" subject line, but I thought it would be better to start a new thread to make it easier to organize...

I've been talking with our Java Batch lead (Scott Kurz) and we came up with some good input, but not necessarily a draft template...  I'll explain.  Scott is not a fan of the current JCP template.  For Java EE 8, he was considering an MR for Java Batch.  The JCP template basically requires you to start from scratch with every new revision.  In many cases, you are just copying-and-pasting from the original to the new template, with only a few sections actually being updated.  He would like to see "common" metadata for a project to be consistent and only require updates to the specific items that are affected by a new release.

I pointed out the Eclipse Release mechanism.  Some of you are familiar with the MicroProfile project.  Here's an example of a Release definition for MicroProfile 1.3:  
https://projects.eclipse.org/projects/technology.microprofile/releases/microprofile-1.3

You can enter as much (or as little) detail required to defined the release content, the release plan, issues being tracked, etc.  Scott liked this type of approach much better.  The overall project information is long-lived (https://projects.eclipse.org/projects/technology.microprofile) and consistent across releases.  But, each release can be further defined as required by the project.

Let's use JAX-RS as a Jakarta example:  https://projects.eclipse.org/projects/ee4j.jaxrs

Currently, there are no additional releases defined for JAX-RS (other than the creation review, https://projects.eclipse.org/projects/ee4j.jaxrs/governance).  But, the JAX-RS project could create a JAX-RS 2.2 Release definition (for example) by specifying a proposed release date:  https://projects.eclipse.org/node/12849/create-release (All of this information can easily be changed after the fact.)  Once the proposed Release is created, then all of the detail specific to that release could be filled out (deliverables, compatibility, milestones, issues, standards, etc).  This is all defined in more detail in the handbook:  https://www.eclipse.org/projects/handbook/#release

If this is an agreeable process, we could require the non-Eclipse based projects (ie. CDI, Bean Validation, Batch) to still have a "holding project" in Eclipse to capture this type of release information.  The main project page could point off to their real location (Red Hat, Apache, IBM, etc) for the project artifacts.  I'm just trying to point out that we would not require all Jakarta projects to be an Eclipse project -- just the release tracking information. This is very similar to the JCP requirements, except lighter weight.

For the Platform, we could aggregate all of the component release information into a single interface that is easy to navigate.

Just an idea to discuss.  We could re-use existing capabilities within the Eclipse foundation without having to invent something new.  I'm sure this Eclipse Release process isn't perfect, but with Wayne on the PMC, I'm sure we could get some tweaks done to satisfy the requirements.  :-)

Some additional ideas for either the static or dynamic content...
  • package prefix (io.jakarta)
  • maven coordinates/URL of artifacts
  • project dependencies (especially other ee4j projects -- Wayne's graphing experiment may help here)
  • project "health" -- something along the lines of Apache project status (committers, community growth, blockers, etc)

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn:
https://www.linkedin.com/in/kevinwsutter

Back to the top