Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec] [BALLOT] Approve the Jakarta TCK package naming convention ee.jakarta.tck.[spec]

Jan,
We only start addressing one urgent issue first to allow some EE 10 TCKs to make progress. The rest will be addressed subsequently. I don't see why we can not tackle the urgent one first.
Thanks
Emily

On Thu, Jan 13, 2022 at 8:34 PM Jan Westerkamp <jan.westerkamp@xxxxxxx> wrote:
-1 (iJUG, not member of the Specification Committee)

Why:
As mentioned in the Platform call, I think this topic needs further and wider discussion.
I think first we need to define an official project structure plan of all the Jakarta[ EE] projects/artifacts, including i.e. specs and APIs.
This need to be a tree, with one root and a hierarchy of nodes having exact defined names. I.e. the root could be "Jakarta" (or Jakarta EE?), and component specs and profiles under it.
Package names and module identifiers (like Maven Group IDs, Artifact IDs etc.) should, while maintaining tool specific naming conventions, reflect that project structure to support maintainability. I.e. the package name from a stack trace should point to the related Maven Artifact where the package is included.

Relating the TCK artifact, they could contain tests on the root level (general tests, like enforcing spec implementations do NOT use the namespace of somebody else) and on other nodes of the project structure, where they belong to, like component specs or profiles (with there related API) - but on that exact level and node - especially not on another or higher (more general) node!

We should not design namespaces to make short cuts in the tool implementation  - we should design to a clean (human and machine) model, that is maintainable, meaning managing complexity and preventing erosion.

A specs TCK is part (sub-node) of that spec project, aligned to the document and API it is defining - that should be reflected in the naming conventions of packages and module IDs to prevent conflicts.

Changing the project structure later is very expensive (remember the package renaming to jakarta.*!), to quality is important. It has also influence on the organisational level (Conway's Law)...

Best,
Jan

PS: When you would like to view at the current existing erosion in Jakarta EE 9.1, have a lock at this ongoing analysis: https://www.eclipse.org/lists/jakartaee-platform-dev/msg03161.html


Am 12.01.22 um 23:22 schrieb Emily Jiang via jakarta.ee-spec:

Greetings Jakarta EE Specification Committee.

After a long discussion on the naming convention of the Jakarta TCK namespaces, the Jakarta community chose the package name: ee.jakarta.tck.[spec]. 


I need your vote to approve the Jakarta TCK package name ee.jakarta.tck.[spec]

Per the process, this will be a seven-day ballot, ending on January 19, 2022, 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.

Thanks


--
Thanks
Emily


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


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


--
Thanks
Emily


Back to the top