Module names for Jakarta EE implementation projects under EE4J

[ivargrimstad]

The jakarta namespace must not be used for implementation projects. Eclipse standard practices must be followed.

The PMC suggests org.eclipse.* as module names for the EE4J projects.

Please add comments and/or suggestions to this issue.

[MrinalKanti]

Shouldn't this be org.eclipse.ee4j.* to differentiate from other eclipse projects/implementations?

[joakime]

Note: org.eclipse.jetty.* is an implementation of both the eclipse-ee4j/servlet-api and eclipse-ee4j/websocket-api specs (pre-jakarta ATM)

[waynebeaton]

The standard practice is to use the project short name for Java packages e.g. org.eclipse.glassfish.*

We don't generally use the Top-Level Project identity in technical namespaces.

[ggam]

Just to clarify, the suggested package name does account only for new projects? Or are the existing ones expected to change package names? El mié., 17 oct. 2018 16:57, Ivar Grimstad <notifications@github.com> escribió:

…

The *jakarta* namespace *must not* be used for implementation projects. Eclipse standard practices must be followed. The PMC suggests org.eclipse.* as module names for the EE4J projects. Please add comments and/or suggestions to this issue. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#35>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACAucBFBagzJVK_z8OhlWpZvyIoxE4-Sks5ul0VwgaJpZM4XkID_> .

[bshannon]

This is only about JPMS module names, not package names.

[ggam]

Oh sorry, that makes sense El mié., 17 oct. 2018 18:38, Bill Shannon <notifications@github.com> escribió:

…

This is only about JPMS module names, not package names. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACAucBW35OydmzrX_brKA2PO6HCgn0yCks5ul1zvgaJpZM4XkID_> .

[MrinalKanti]

If its just for JPMS module names then why not just use ee4j.* ? I believe JavaFX uses a similar convention.

[ggam]

I think EE4J should remain mostly as "an implemention detail". EclipseLink and Yasson for example moved to EE4J from another top level project. Potentially other projects in the future might do it, or EE4J projects can go out. El mié., 17 oct. 2018 18:46, Mrinal Kanti <notifications@github.com> escribió:

…

If its just for JPMS module names then why not just use ee4j.* ? I believe JavaFX uses a similar convention. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACAucDrF_XzxgmkkI8g236tHTcPpySVTks5ul17zgaJpZM4XkID_> .

[m-reza-rahman]

I think this is mostly a no-brainer unless I am missing something. org.eclipse.* is fine.

[rhuan080]

I think org.eclipse.ee is good to use.

[bshannon]

One of the things we learned with Java EE is that the association with "EE" can blur over time so just like Wayne says we shouldn't include "ee4j" in the name, I would suggest that we not include "ee" in the name.

[rhuan080]

Yes @bshannon. You are correct in that. But I think we need refer that this project is about enterprise. With this, I suggest org.eclipse.enterprise. Can we use that?

[bshannon]

Why does it matter that it's "about enterprise"? Many of these API are used standalone in
a very non-enterprise environment.

[rhuan080]

Because the main goal is provide solutions to enterprise, although it is used in a non-enterprise environment.

[karianna]

I think the world has moved away from 'enterprise', Jakarta EE / EE4J is looking to the future which is both traditional enterprise and Cloud Native Cheers, Martijn

…

On Fri, 19 Oct 2018 at 00:09, Rhuan Rocha ***@***.***> wrote: Because the main goal is provide solutions to enterprise, although it is used in a non-enterprise environment. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALCaAMI4Tf4bkYIZrR05ml0DMKSfsgQks5umQo0gaJpZM4XkID_> .

[m0mus]

Module names should be derived from Maven groupIds. The recommended Maven groupId for EE4J projects is org.eclipse.<project-name>. So, the module name should be also org.eclipse.<project-name>.

For example:

org.eclipse.jersey
org.eclipse.soteria

[joakime]

If a project has multiple artifacts, the Maven groupId will turn into a prefix for the Module name.

Most of the artifacts being produced already in the various eclipse-ee4j projects already have an OSGi bundle name declared.
Wouldn't it be nice if we could align the OSGi bundle name and the JPMS Module name?

Note that we cannot rely on using the existing OSGi bundle name as-is.
Unfortunately JPMS Module names have different syntax rules (eg: cannot use hyphens in the name for JPMS)

Eg:

• org.glassfish.tyrus.bundles.websocket-ri-bundle is OK for OSGi but the hyphens are not allowed on JPMS
• org.glassfish.tyrus.bundles.websocket.ri.bundle is OK for JPMS and OSGi.

[m0mus]

@joakime Yes, you are right. What about this:

It should be groupId.artifactId if artifactId doesn't contain the groupId as prefix and artifactId if it does contain groupId as prefix.

[jodastephen]

Modules are not artifacts. So it is important to not let maven group/artifact names drive module names. (Yes there is a link, but module naming should start from the package name, not the artifactId).

The idea of using org.eclipse.* for Eclipse hosted implementations is good. As is the idea of omitting ee and ee4j.

The module names should really match the root package name as per my naming recommendations. So, IMO this issue should focus on package naming for implementations, with the module name dropping out by virtue of being the root package name.

[smillidge]

Given the Eclipse Foundation also owns the GlassFish trademark what is wrong with retaining org.glassfish for those that already have that group id?

[bshannon]

I agree. It seems fine to use org.glassfish.

[smillidge]

Are we agreed on org.glassfish for implementation projects under EE4J that currently have those package names? I will close in 7 days if no more comments?

[smillidge]

OK org.glassfish should be used for implementation projects that currently have those package names.