I suppose it depends on whether the JavaEE 8 version of Eclipse GlassFish is using the Oracle javax apis jars or the Eclipse released api jars?
If Eclipse under Jakarta EE then all api projects will also have to make a release before Eclipse GlassFish JavaEE 8 can be built.
Also can we release APIs under the Jakarta group id without spec committee approval and therefore a fully formed spec process?
I may be wrong but I thought the order was Eclipse GlassFish built using Eclipse spec implementation binaries but Oracle javax api definitions and tested against the Oracle licensed TCK and therefore
JavaEE 8 compliant.
Second step all specs and apis released as Jakarta EE 8 under the Jakarta group id. Followed by a build of Eclipse GlassFish against these these api jars and tested against the Eclipse released TCK
and therefore Jakarta EE 8 compliant.
Perhaps I am just confused!
Steve
From: ee4j-pmc-bounces@xxxxxxxxxxx <ee4j-pmc-bounces@xxxxxxxxxxx>
On Behalf Of Ivar Grimstad
Sent: 17 September 2018 08:58
To: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Subject: Re: [ee4j-pmc] Action item: use of the jakarta groupId
I am a little curious as to why it should affect the GlassFish release...
As David pointed out earlier, it is a one-line change in the spec pom.xml files, so that is close to no overhead at all. And the dependencies to the Eclipse-released specs must be changed anyway because of the new version number, so there
is close to no extra overhead by changing the groupId to jakarta at the same time. It may actually save some time since we will have the check that we have not forgotten to update any dependencies since we can scan for javax-groupIds...?
+1 in principle however I also have concerns on timing given the next release of GlassFish will be a JavaEE 8 compatible release. Do we switch now for the JavaEE 8 versions or later
when the Jakarta EE working group releases the specs?
Shouldn’t the JavaEE 8 version of Eclipse GlassFish use the Oracle released javax apis?
Steve
Subject: Re: [ee4j-pmc] Action item: use of the jakarta groupId
PMC, we should finish voting and make a formal statement about it. I still don’t see that all PMC members are voted.
David: +1 (It was suggested by David, so I believe that he’s voting +1)
Ivar: ? (From your email I understand that you support it, but I didn’t see your +1)
Kevin: ? (From your email I understand that you support it, but I didn’t see your +1)
Dmitry: -1 (I support this change in general. My concern is about deadlines and delaying GF release because of it. I will change my vote if I get a confirmation from all vendors
that they will push their project leads to make this change smoothly.)
Following up from the specification committee meeting. We (PMC) need to make sure all the specifications/api jars we release to Maven Central are in the jakarta groupId. Using
JMS as an example:
If you want an easy command to do it:
$ perl -i -pe 's,Id>javax,Id>jakarta,g' pom.xml
We'll need to re-release JAX-RS and make sure we add this to our spreadsheet to track which projects have done it.
Here's the document for reference with motivations on the change in Maven coordinates:
_______________________________________________
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
--
Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader
