Change project name to Jakarta Messaging

[ivargrimstad]

Background information:
https://waynebeaton.wordpress.com/2019/04/04/renaming-java-ee-specifications-for-jakarta-ee/

Checklist:

• GitHub
• README file
• NOTICE.md file
• Eclipse Project under https://projects.eclipse.org/projects/ee4j

[ivargrimstad]

Jakarta Messaging?

[arjantijms]

Jakarta Messaging seems the better name.

As per my other comments in e.g. JCA, "Service" is a similar word as "Architecture", "Utilities", "Framework", and "API" used in other specs. I don't think JMS is any more a service than JCA is an architecture, JPA is an API and JSF is according to its name neither of those.

[keilw]

It sounds reasonable, but what about the namespace and package naming? Everything that's under javax.jms right now, if a strict change to jakarta.something was forced even for existing APIs (that seems a subject to discussions between Eclipse and Oracle Legal from what we heard) what would the package and Maven coordinates be? It is jakarta.jms now for Maven. So I don't see that being changed easily without friction and issues when migrating. If calling it "jakarta.jms" on the package level and "Jakarta Messaging" (dropping the "Service") on the outside, guess that could be OK. Especially if other specs may do something similar.

The JCA example is slightly odd because the namespace was never "javax.connector" or something, it was "javax.resource" (now "jakarta.resource"). So cleaning that up seems a very good idea, especiall because "JCA" is also used for "Java Cryptography Architecture" in the Security/SE context.
Looking at "Enterprise Java Beans" becoming "Jakarta Enterprise Beans" that spec is probably most comparable to JMS because the namespace is "javax.ejb" right now and became "jakarta.ejb". If EJB finds a way to argument around the name twist from "EJB" to "JEB" I guess "Jakarta Messaging" by simply dropping the "Service" could also work.

[ivargrimstad]

If we are changing from javax.jms to something else it might as well be jakarta.messaging. No reason to keep the jms package name then?

[bshannon]

I agree.

[arjantijms]

Absolutely, if the project name changes, and the package name has to change anyway, it’s a good to match them.

[keilw]

Once it's changed, sure, not sure about "ejb" but of course it could also change to something more drastic like "jakarta.enterprise.beans" or "jakarta.jeb" ;-)

[keilw]

So if it should be "Jakarta Messaging" how about fixing the title of this issue?

[ivargrimstad]

I'll fix it :)

[dblevins]

I also agree that Jakarta Messaging is the natural name and the namespace should be jakarta.messaging

It's been a month and we haven't seen any disagreement. If we don't see disagreement in the next couple days, I say we close this issue as accepted and resolved May 31st.

[keilw]

Are all the individual items checked off or ready before Friday? So jakarta.messaging would be both package and groupId from Jakarta EE 9, but for 8 only the overall title changes?

[nigeldeakin]

Sounds good. I would add that having the word "service" in JMS has always been misleading because it suggests that "JMS" is an implementation rather than an API, so dropping it in the new name is a good idea.

Is it obvious that the new name refers to an API, or do you need to append "API" to the end (at least in the formal name of the specification)?

[keilw]

As it was mentioned in another ticket, not only JMS have API elements like javax.jms.JMSConsumer which whenever the actual package gets renamed either have to be deprecated with a replacement in the new API (that's what we did in JSR 385 when we found ParserException was to broad and introduced MeasurementParseException) or the harder change would be to rename it into say jakarta.messaging.MessageConsumer (or MessagingConsumer) which of course would make backward-compatibility of any kind even more tricky.

[arjantijms]

On Thu, May 30, 2019 at 11:15 AM Nigel Deakin ***@***.***> wrote: Sounds good. I would add that having the word "service" in JMS has always been misleading because it suggests that it defines an implementation rather than an API, so dropping it in the new name is a good idea.

Thanks Nigel, especially good to have support from you for this. Do you happen to remember or know who came up with the term "service" and why it was chosen back then? (I realise it's a long, long time ago). Just curious ;) Kind regards, Arjan

[nigeldeakin]

Do you happen to remember or know who came up with the term "service"

I don't know (the name is over twenty years old!)

[nigeldeakin]

Just for information: in addition to various JMS 2.0 interfaces and annotation types containing the characters "JMS", note also that the Java EE 8 platform specification defines the deployment descriptor elements <JMSConnectionFactoryDefinition> and <JMSDestinationDefinition>, which correspond to the JMS annotations of the same name.

[dblevins]

Thanks Nigel, especially good to have support from you for this. Do you happen to remember or know who came up with the term "service" and why it was chosen back then? (I realise it's a long, long time ago). Just curious ;)

Likely, Mark Hapner. He created the first JMS specification as far as I'm aware.

[keilw]

Thanks Nigel, that helps understand the possible implications for a compatibility mode or conversion tool of some kind.

[dblevins]

Also some historical context on "service", back then service meant something different. The mindset of the time attempted to classify things as either a "component" or a "service." There was frequent debate on the difference between a component and a service. It tended to follow the perspective of "a component is a business object you write", and "a service is something offered to your component that it can use". JMS was thought of as a service because it was something provided by the implementation and used by your components.

Now service has a different meaning.

[OndroMih]

Hi @dblevins, @ivargrimstad , can we close this issue? It's done, isn't it? We didn't change the package prefix to jakarta.messaging but we're not going to do it in the future because we don't want to break things again, do we?

@waynebeaton, is there a reason why this issue is still in To do in Jakarta Specification Project Names?

[OndroMih]

It seems that we just need to update https://github.com/eclipse-ee4j/jms-api/blob/master/NOTICE.md and then resolve this issue.

I've raised #290 to do it.

[arjantijms]

@OndroMih to fully resolve this, a bug needs to be filed with Eclipse to fully change the name. Notice how the project URL still says https://github.com/eclipse-ee4j/jms-api/

I did this for e.g. https://github.com/eclipse-ee4j/authentication

[arjantijms]

If nobody objects here, I'll file the bug later this week.

[OndroMih]

If we're talking about URLs, shouldn't we also change the URL of the project page https://projects.eclipse.org/projects/ee4j.jms?

So the following should be changed:

• https://github.com/eclipse-ee4j/jms-api/ -> https://github.com/eclipse-ee4j/messaging-api/
• https://github.com/eclipse-ee4j/jms-propsals -> https://github.com/eclipse-ee4j/messaging-proposals (notice the type in the old name which I fixed in the new name)
• https://projects.eclipse.org/projects/ee4j.jms -> https://projects.eclipse.org/projects/ee4j.messaging

@arjantijms, please file a bug for Eclipse Fnd to change those. Both github and Eclipse project pages redirect old URLs to new ones so it's safe to change the URLs.

There's also the mailing list jms-dev, but I think it should keep its current name. I see that authentication also kept the old name jaspic-dev for the ML. It's a global name and so we would have to change it to something like ee4j-messaging-dev or ee-messaging-dev which is too long. But we can do it too, if we need to, what do you think @waynebeaton, @ivargrimstad ?

[arjantijms]

The bug was filed here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=573784

[arjantijms]

Project rename concluded, thanks everyone for all input.