Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-pmc] Jakarta EE / EE4J Technical Vision document
Dmity,
Yep, it depends on how we approach this "technical direction"...  Based on our discussion at the last PMC, we thought we would solicit input from each (or many) of the components.  This would require some type of "template" asking for input.  Thus, I went down that path thinking of using the Eclipse Release request for each component to identify their "next release" plan...  But, as you say, maybe that's more of a project release plan -- which is different from a technical vision document.

I read through your blog...  This is a good start, as well.  A few comments...
  • I like the division of the TCKs to their respective API projects.  As you say, major piece of work.  Requiring the same test framework may be difficult.  Hate to speak for Red Hat, but I doubt that they will be moving CDI and Bean Validation away from Arquillian -- unless Arguillian is chosen as the common test framework.  But, in that case, then all of the rest of the TCK buckets have major work...  :-)
  • Have to be careful on how far we embrace Java 9 modules...  Some of us (Red Hat, Payara, and IBM) use alternate module systems.  We can't alienate these implementations.
  • Standardizing on Maven is good.  And, standardizing the artifacts.
  • Marking old and unused technologies as optional or deprecated is good.  We probably need to define a deprecation policy.  Is that us?  Or, the Spec committee?  Specific to your comment about JPA-RS...  Wouldn't that just be considered an implementation detail that EclipseLink has and it could be deprecated based on EclipseLink project rules.  It's not required for the JPA spec implementation, so we (PMC) shouldn't care.
  • Your comment about integration with CDI and Config...  We should also consider the eventual integration with the MicroProfile features.  Some will have a natural evolution like merging Rest Client with JAX-RS (already being discussed).  But, others like Config would need to be a new component project under EE4J.  I think we need to put the MicroProfile integration into our Technical Vision.
Thanks!

---------------------------------------------------
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



From:        Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>
To:        EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Date:        05/18/2018 02:24 PM
Subject:        Re: [ee4j-pmc] Jakarta EE / EE4J Technical Vision document
Sent by:        ee4j-pmc-bounces@xxxxxxxxxxx



Hi,

It looks good and I like your idea, but my understanding of technical directions PMC should provide is different. It doesn’t mean that what you’ve done is wrong. Possibly it’s just my misunderstanding.

You are talking about a project release plan describing what project is planning to achieve in the next release. This is not technical directions for all EE4J projects, it’s one particular project plan. It will be required by the spec committee for the initial spec review.

My understanding of technical directions is that it’s a set of recommendations for all EE4J projects. It contain general issues projects should address. I also spent some time with Prague folks and we came out with a document published here: https://dmitrykornilov.net/2018/05/18/jakarta-ee-technical-directions/. This is our vision of technical directions. Consider it as a draft. It should be discussed by the community. At the end PMC should review all community comments and create a final technical directions statement.

Thanks,
Dmitry


On 18 May 2018, at 20:14, Kevin Sutter <sutter@xxxxxxxxxx> wrote:

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
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-pmc



Back to the top