search

jakartaee / JESP

Jakarta EE Specification Process
4 stars 6 forks source link

Wording in the JESP for migrating projects from anywhere other than the JCP #6

Open keilw opened 3 years ago

keilw commented 3 years ago

This is vagely related to #5 but a slightly different case.

If a specification was get contributions from an "external specification" using a different namespace, e.g. "org.eclipse.microprofile", "org.springframework", "io.cncf", "io.opentracing", etc. (just few examples) for improved "Cloud Nativity" or another need, would that be legitimate, or not? As the namespace is currently specified to be "jakarta" and other possible conflicts like different IP regimes, etc. may also arise from this.

ivargrimstad commented 3 years ago

I am not sure if we need any changes to accommodate this. The wording in the JEST is that the jakarta namespace MUST be developed within the Jakarta EE Working Group. It does not state that it is limited to this namespace.

keilw commented 3 years ago

Aside from procedual questions or "Brand integrity" and identity (take Spring Boot which despite hosted under spring.io still keeps using the same old org.springframework.* namespace it has done for 20 years or so) the most simple argument against that (not only for Jakarta REST) is it would create package-splitting. Jakarta REST has defined a module-info with the current module name jakarta.ws.rs even before it came to Jakarta. If this module suddenly exported jakarta.ws.rs.client and org.eclipse.microprofile.rest.client then any other modules also exporting this package (even if it's an older version of MP with automatic module name from the JAR) could break a modular app that finds both in the classpath/modulepath. That means if a new version of Jakarta REST was polluted that way, any vendor and Jakarta EE runtime that also shipped with an earlier version of MicroProfile would have to eliminate that immediately or force an upgrade to an MP platform without mp-rest-client. I don't think the MP-friendly Jakarta implementors would like to take that risk.

edbratt commented 3 years ago

@keilw It should not be the case and I do not think that it was intended that an external Spec. would be precluded from being re-homed here under the JESP. That would need to be done under some kind of agreement from the original body and certainly under the terms of the specification's license and copyright.

edbratt commented 3 years ago

All contributions to work here is covered under either the contributor's contribution agreement, or subject to third party IP review. I think that covers all potential avenues for contribution.

keilw commented 3 years ago

@edbratt I suppose you know the reasons behind the original wording best why there was a need to mention "javax" to "jakarta" specifically. If any other paperwork including the contribution guidelines are needed from case to case, then another spec also governed by the EFSP could be in a better position. Aside from that I am convinced, we should at least mention the problem of possible package-splitting somewhere, ideally in the Jakarta EE platform specification or a similar document beside pointing to what the Java SE platform and module systems provide and require when it comes to modularity. Because even if say this whole "CDI Light" discussion came up with new modules there are a few specs like CDI that spread across multiple first level packages and if e.g. any element was to move from one Jakarta Spec (like CDI) to another (like Injection) they could not keep the same package either without splitting the package.