Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-pmc] Action item: use of the jakarta groupId

Thank you so much, Guillermo!  Look for a little shout out in the Sept 25th Steering Committee meeting minutes :)

On Wed, Sep 19, 2018 at 12:27 PM Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:
Hi,

Just FYI: I went through all the available repositories that haven't been already changed and submitted PRs on all of them. Some of them have already been merged.


Regards,

Guillermo González de Agüero

El mié., 19 sept. 2018 a las 15:36, Kevin Sutter (<sutter@xxxxxxxxxx>) escribió:
I am also a +1 on doing this now...

But, a fair question was raised in this string of notes...  Will the outliers (Batch, CDI, and Bean Validation) also re-release using the Jakarta groupid?  I think they should to be consistent.  Seeing Mark's +1 reminded me of this scenario.  

---------------------------------------------------
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:        Mark Little <mlittle@xxxxxxxxxx>
To:        EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Date:        09/19/2018 04:26 AM
Subject:        Re: [ee4j-pmc] Action item: use of the jakarta groupId
Sent by:        ee4j-pmc-bounces@xxxxxxxxxxx




+1

On 14 Sep 2018, at 22:46, Martijn Verburg <martijnverburg@xxxxxxxxx> wrote:

I’m +1 to this personally - a clean break and demarcation is really important

On Fri, 14 Sep 2018 at 21:55, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
For me personally, I consider marketing a side benefit.  A good one, but still a side benefit.

Speaking only personally, the bigger concern is having our future API jars in some way split between javax and jakarata groupIds.  I fear the trail of frustration we'd leave behind by slowly and inconsistently evolving the groupIds over the next few years.  It would be possible for us "old guard" navigate, but for new people it would be a frustrating task to continuously hunt around for the right artifact.

As we have to release all the jars again as the license file is changing, this seems like the best opportunity for a clean break and a simple rule "If it is a Jakarta controlled spec, you find it in jakarta groupId.  If it is still controlled by the JCP, you find it in javax."

I think the line between the JCP and Jakarta will in general be hard for developers, even us ("Is JCache JCP or Jakarta??") and this can help clarify.

That's just my own personal opinion.  No one needs to share it or be convinced.  If people want to think of it as a purely marking thing and that motivates them, that's fine too.  It's really the destination that's important and how we each get there can be different.

--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852

On Sep 14, 2018, at 10:38 AM, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:

Ivar,
 
thanks for the explanation.
 
So what I take from it is:
 
* There is neither a technical nor a legal reason for "MUST change groupd ID" for being released to OSSRH.
* There is a wish that groupd ID "SHOULD be changed" before being released solely for markeing purposes.
* To become an *official Jakarta EE API*, the groupd ID of an API MUST be release, as this is simply WANTED by the spec committee.
 
I could live with that.
 
-Markus
 
 
From: ee4j-pmc-bounces@xxxxxxxxxxx[mailto:ee4j-pmc-bounces@xxxxxxxxxxx] On Behalf Of Ivar Grimstad
Sent:
Freitag, 14. September 2018 09:27
To:
EE4J PMC Discussions
Subject:
Re: [ee4j-pmc] Action item: use of the jakarta groupId

 
Hi Markus,
 
Changing from javax to jakarta for the groupId is purely for communication purposes. By using jakarta as groupId, we signal that it is a Jakarta EE artifact and not just an update to one from the JCP.
It will make it easier for developers to know what dependencies they add to their applications.
 
By using the same version number and only changing the maven groupId to jakarta, we communicate that there are no changes other than that it is produced by Jakarta EE. This makes sense since it will be certified by the Java EE 8 CTS.
 
Changing the package names has more technical implications and will probably break a lot of things that relies on e.g. reflection. That is why the legal agreement between Oracle and Eclipse Foundation regarding this is so important, so existing specs can continue to use the javax package names.
 
Hope this clarifies a little.
 
Ivar
 
On Thu, Sep 13, 2018 at 11:07 PM Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
I want to learn, so please tell me: Why must the *Maven groupId javax* be abandoned by JAX-RS, while we MAY keep the *package name javax*?
-Markus

-----Original Message-----
From:
ee4j-pmc-bounces@xxxxxxxxxxx[mailto:ee4j-pmc-bounces@xxxxxxxxxxx] On Behalf Of Mike Milinkovich
Sent: Donnerstag, 13. September 2018 15:56
To:
ee4j-pmc@xxxxxxxxxxx
Subject: Re: [ee4j-pmc] Action item: use of the jakarta groupId

On 2018-09-12 5:28 PM, Guillermo González de Agüero wrote:
> My arguments assumed that it has to be done and that we just have to
> decide whether to do it now or later.

That is correct. The technology formerly known as Java EE is being migrated from Oracle to the control of the Eclipse Foundation and the Jakarta EE Working Group.

This *must* be done. The only topic for debate is timing.

--
Mike Milinkovich

mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
(m)
+1.613.220.3223


---
This email has been checked for viruses by Avast antivirus software.

https://www.avast.com/antivirus

_______________________________________________
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

_______________________________________________
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
--
Cheers, Martijn (Sent from Gmail Mobile)
_______________________________________________
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

---
Mark Little

mlittle@xxxxxxxxxx

JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)



_______________________________________________
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

_______________________________________________
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