Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-pmc] Specification project scope statements

Hi,

As I recently proposed on the spec committee call, coming up with new names does give us the opportunity to simplify the existing names and make them more consistent.

We now have names like:

Concurrency Utilities for Java EE
Java EE Security API
Java API for JSON processing
Java API for WebSocket
Java Persistence API
Bean Validation

It's actually quite inconsistent when you take a good look at it. Some start with "Java API" and then have some tech name after it. Others have the tech name in the middle. Some don't have API in them at all. Why for instance is WebSocket a "Java API", but Bean Validation is just Bean Validation? Why is Concurrency a "Utilities" and not an "API"? Why does Security have Java EE in front of it, but Concurrency has if after it, etc etc

One proposal we could do is to make those names consistent, and as short as possible. That might make the need for abbreviations a moot point as well. As I mentioned on the call and talked about in person with Ivar, nobody ever abbreviates say "Spring Security" to SS or SSe or something.

An example for the above could be:

Jakarta Concurrency
Jakarta Security
Jakarta JSON-P
Jakarta WebScoket
Jakarta Persistence
Jakarta Validation

Kind regards,
Arjan




















On Thu, Apr 4, 2019 at 6:59 PM Reza Rahman <reza_rahman@xxxxxxxxx> wrote:

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

 

From: ee4j-pmc-bounces@xxxxxxxxxxx [mailto:ee4j-pmc-bounces@xxxxxxxxxxx] On Behalf Of Ivar Grimstad
Sent: Donnerstag, 4. April 2019 08:34
To: EE4J PMC Discussions
Subject: Re: [ee4j-pmc] Specification project scope statements

 

Hi,

 

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.

 

Ivar

 

 

 

On Thu, Apr 4, 2019 at 7:36 AM Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:

 

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


_______________________________________________
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

Back to the top