Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec] [BALLOT] Approval to update the Jakarta EE Specification Process (JESP)
-1 (iJUG, non binding community vote)

Why:

As mentioned before (https://www.eclipse.org/lists/jakarta.ee-spec/msg02165.html), I still think this is a Pyrrhic victory:

With this decision the JESP manifests the ballot result regarding the package naming convention for Jakarta EE 10 (put the TCK somewhere except jakarta.<SPEC_NAME>) and Jakarta EE 11 (put it to package ee.jakarta.tck.<SPEC_NAME>), which allows specification implementing projects continuing the direct and indirect use of the jakarta namespace, while disallowing that use to the specs itself, i.e.:

Spec implementations are allowed to have (unit & integration) tests using jakarta.<SPEC_NAME> (direct use).
Spec implementations are allowed to make weak assumptions about their System Environment's use of that namespace to do simpler filtering for their workloads (indirect use).
Spec project APIs not allowed to use that namespace for tests any more!
Spec project TCKs not allowed to use that namespace either!

The result is: The tests, that belong the the spec project itself, are bounded weaker to it than the tests of their implementations regarding the package naming conventions. This implies the project structure is not reflecting the cohesion of the components and may separating the responsible organisations.

I expect this will create a lot additional issues and discussions in the future, i.e.:

I have a log entry with a stack trace showing package jakarta.<SPEC_NAME>.* - where to file the issue?
I have a log entry with a stack trace showing package ee.jakarta.tck.<SPEC_NAME>.* - where to file the issue (hint: the project homepage has the same root ;-) )?
Where to find the artefact containing that code?
Why it might have the namespace root ee.jakarta, when I do not use a Jakarta EE Profile at all (because the implementation is based on top of Java SE only, aka stand-alone)?

Not well defined yet are i.e. the Maven coordinates to be used for the spec's TCKs - but when I interpret the definition of this ballot, it must be separate form the one of the API (same for OSGi and JPMS if applicable).

And these issues will not only occur inside vendor organisations with experienced and paid staff implementing Jakarta specs only, this could occur in projects that have the goal to maintaining software quality with CI like Adoptium AQAvit or new Contributors to the spec projects that need to handle this additional complexity.
Within Jakarta having stable (and obvious) references for the component spec TCK is very important, as they might reference dependent specs TCKs as a hole or partly with a subset to reach the necessary test coverage from their perspective - without the need for duplicating the test code.

Therefore this decision adds complexity for the long run (while solving some on the short run), which results in lower maintainability and quality at the end - which is not a goal for a specification in general.

Further it is necessary to mention this is special to Jakarta, as i.e. MicroProfile shows that it is legally and technically possible to have the same namespace root for the spec API and the TCK - so this will result in a persistent difference of these projects too.

One of iJUGs reasons to join this WG is to bring in the user perspective and link the community to the spec projects tighter, i.e. with improved bidirectional communication, finding new Contributors/Committers etc.. Decisions like this do not make this task easier because additional complexity need to be explained.

So as a representative of (some German speaking part of) the users community I have to vote against it, even while knowing I may represent a minority with a non binging vote here.

Best, Jan

PS: Some of the issues regarding the Jakarta EE profile implementations could have been achieved with a decision to put component specs TCKs at the jakarta.<SPEC_NAME>.tck.* namespace instead - without that collateral impact...


Am 22.02.22 um 14:07 schrieb Ivar Grimstad:
Greetings Jakarta EE Specification Committee.

I need your vote to approve the following change to the JESP to accomodate the need to tighten up the language around the usage of the 'jakarta' namespace.

The JESP/EFSP requires a successful ballot of the Specification Committee in order to approve changes to the JESP.

The relevant materials are available here:
- Text added:

"Use of the `jakarta` namespace is limited to API artifacts (all API jars, javadoc, and schema namespaces). It must not be used for any deployment, including applications, TCKs, tools, libraries, or any other assets produced by Specification Projects."

Per the process, this will be a seven-day ballot, ending on 2022-03-01 that requires a Super-majority positive vote of the Specification Committee members (note that there is no veto). Community input is welcome, but only votes cast by Specification Committee Representatives will be counted.

The Specification Committee is composed of representatives of the Jakarta EE Working Group Member Companies (Fujitsu, IBM, Oracle, Payara, Tomitribe, Primeton, and Shandong Cvicse Middleware Co.), along with individuals who represent the EE4J PMC, Participant Members, and Committer Members.

Specification Committee representatives, your vote is hereby requested. Please respond with +1 (positive), 0 (abstain), or -1 (reject). Any feedback that you can provide to support your vote will be appreciated.

--

Ivar Grimstad

Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration. 


_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec


Back to the top