Could a specification project consume "External Specifications"?

[keilw]

The JESP currently states:

All development that modifies content in the javax namespace must be moved to a jakarta namespace. All jakarta namespace >development must occur within the scope of a Specification Project operating under the purview of the Jakarta EE Working >Group’s Specification Committee and must implement the process as defined by the most recently adopted revision of the JESP.

If a specification was to consume "external specifications" 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.

[paulbuck]

My understanding is that the language quoted here from the JESP requires the evolution of code in the jakarta namespace to happen under the Jakarta EE Working Group. It does not however say that a Jakarta EE specification cannot define code in a different namespace.

[keilw]

I believe the namespace question is probably even more relevant to #6 although @ivargrimstad also mentioned it does not explicitly outrule or prevent "com.xyz", "org.xyz" or "io.pqr" namespaces either.

[edbratt]

My understanding is that the language quoted here from the JESP requires the evolution of code in the jakarta namespace to happen under the Jakarta EE Working Group. It does not however say that a Jakarta EE specification cannot define code in a different namespace.

+1
my recollection is, this language codifies the migration of Oracle contributed code that formerly had been under the javax namespace -- to the jakarta namespace. I do not believe there was any intention to restrict or limit use of, development of, or adoption of code from other namespaces.

[om8n]

GG33

[keilw]

What is that supposed to be, who the hack is this @om8n user and was the thread hijacked or hacked?

[keilw]

@edbratt @paulbuck I assume it is less of a problem here, unless of course certain "toxic" license models that are incompatible with Jakarta EE and the ones applied could be an issue.
As for #6 there package-splitting is a far bigger issue than license or other concerns. As everywhere especially with Open Source you cannot undo the prior modules and efforts or put the "Genie" back into its bottle, therefore if anything was added to an existing Jakarta module, that existed in another "module" (even if not explicitly declared as such but those are still unnamed or automatic modules) it must not use the same package there otherwise it would create a conflict. I don't think, we need to declare it as such because the Java SE Module System does, but maybe some more highlighting of such problems and how to avoid them would be good for Jakarta EE 9.1 or 9.2 ;-)

[edbratt]

@keilw I do not believe the text in question is intended to have any influence over those questions.