What we actually need is a final and official statement from the EF that we definitively MUST rename everything, so we could start NOW.
Arjan proposed to do it and was stopped by Bill two weeks ago. Two more list weeks IMHO.
EF, please tell us how long to wait.
-Markus
From: ee4j-pmc-bounces@xxxxxxxxxxx [mailto:ee4j-pmc-bounces@xxxxxxxxxxx] On Behalf Of Reza Rahman
Sent: Donnerstag, 4. April 2019 18:59
To: EE4J PMC Discussions
Subject: Re: [ee4j-pmc] Specification project scope statements
As much as I really dislike it and believe still do many people in the community, I think we should accept that we needed to give up on the naming struggle. The really big thing that I hope will be sorted out properly is backward compatibility with "javax", including being able to enhance the existing APIs without getting into an entanglement with Oracle's small army of lawyers with not much useful to do.
Aside from this, I would really like things to move forward. The longer this drags on, the harder it is going to be to make Jakarta EE relevant, even to Java EE developers.
On 4/4/2019 12:46 PM, Markus KARG wrote:
This sounds like the negotiations to still use the name "Java Message Service" has definitively failed?
So in future we will not define singleton standards for the complete Java universe anymore, but solely a standard for those that want to use Eclipse Jakarta?
This is exactly what the Java EE Guardians wanted to prevent. We could have simply forked Java EE years ago then, without any waiting for Oracle at all.
My hope when entering the Jakarta project was that Oracle allows us to further developed the set of official Java standards, under the original names.
-Markus
I think what we need is a scope statement for the project. The current suggestion is that when the transition to Jakarta EE Specification projects is done, the project name and the specification name will be equal. For example:
- The project "Eclipse Project for JMS" will be named "Jakarta Message Service"
- The specification "Java Message Service 2.0" will be named "Jakarta Message Service"
I am not sure if this ambiguity will cause some confusion or clarification...
The scope of the specification project is suggested to be the specification Document, API and TCK.
There are some discussions going on whether the TCK should be within the scope of the specification project or not. Conceptually, and practically, it should be within the scope of the project, but not under the same license. Not sure if that is possible...
If the TCK should be in its own project, it does not make sense to include it in the scope of a specification project.
All that says is: "Eclipse Proeject for JMS provides the API and TCK for Java™ Message Service (JMS) API, starting from the specification defined by JSR-343."
> This is actually a bad example that needs to be changed. It makes no attempt to actually define the scope of JMS. It's basically self-referential.
Actually it is not self-referential. The project "Eclipse Project for JMS" is a different thing than "Java Message Service API" itself. One is a group of committers, the other is a technology they work on. The cause of this "self-referenceis that "somebody" decided that all projects for Java EE technology are named "Eclipse Project for X". It would be more clear if the sentence would read like "Eclipse Hermes provides the API and TCK for JMS, the official standard for MOM drivers on the Java platform.".
So what do you actually want to have, a description of the project or a description of the technology?
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.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://www.eclipse.org/mailman/listinfo/ee4j-pmc
