|Re: [jakarta.ee-spec] [BALLOT] Revised: Recommend naming convention for new TCK tests in Jakarta EE 10 - Ends Jan 26th, 6pm Pacific|
Despite many -1s and 0s, it does appear people are in agreement and it was only the vote text that lacked detail. This revised vote is an attempt to address that. # Background A discussion starting December 17th on the Platform dev list pointed out several of the spec projects organically started using jakarta.tck.* as the package name for new TCK tests. That discussion revealed there are technical, trademark and certification concerns with this. - Technical: Some implementations handle the jakarta.* namespace specially, so if applications in the TCK use it, those TCK applications will not deploy. EclipseLink is one of the implementations, which is used by 15 or so of our certified platforms, so this would be a fairly global issue if the jakarta.tck.* trend continued. - Trademark: Application developers cannot legally create original code in jakarta.* anyway, so there is no merit to putting TCK test applications in that namespace and/or forcing vendors put workarounds in their product to specially handle jakarta.tck.* - Certification: due to the above, implementations could rightfully argue for tests in jakarta.* to be excluded. This would effectively mean very low test coverage for new Jakarta EE 10 features. Please use the this thread if you'd like to discuss/challenge the above: https://www.eclipse.org/lists/jakartaee-platform-dev/msg03014.html # Status Several specification teams are awaiting undisputed guidance on a new namespace so they can repackage their jakarta.tck.* tests. Jakarta EE 10 is being delayed by lack of guidance on how to handle TCK tests in jakarta.tck.* # Attempts to Resolve - The Platform project collected namespace candidates, held a poll and selected ee.jakarta.tck.[spec] as the namespace. In that conversation it was clear this would be a recommendation for EE 10, not a requirement. It was rightfully pointed out the Platform project doesn't have the authority to make a namespace decision for other projects and the Specification Committee should in some way ratify the result. - The Specification Committee ballot we just saw attempted to ratify that result. The details on it being a recommendation for Jakarta EE 10 where missing and despite clarification, the vote did not pass. No one with a binding vote expressed concern over ee.jakarta.tck.* package itself. # Vote The revised vote text: - Specification projects may not use any form of jakarta.* for their TCK tests. Tests that do so must be renamed to some other package of their choosing prior to the Jakarta EE 10 release. - The recommended package and naming convention is ee.jakarta.tck.[spec]. This is a recommendation for Jakarta EE 10, not a requirement. - Specification teams should anticipate this becoming a requirement in some future date, perhaps even as soon as Jakarta EE 11 and possibly only for new Jakarta EE 11 tests or Jakarta EE 10 tests that did not follow the recommendation. However, this is not decided and those details are intentionally TBD so as to not inadvertently create more sources of disagreement and further delay of Jakarta EE 10. Jakarta EE.next requirements and potential disagreement over vote text and scope can be handled separately. This is a seven-day ballot, ending on January 26, 2022, that requires a Super-majority positive vote of the Specification Committee members. All votes welcome. Please respond with +1 (positive), 0 (abstain), or -1 (reject). Any feedback that you can provide to support your vote will be appreciated.
I'm still -1 (community input) on voting without considering
community input on picking the package name that will be required
for new tests at a future date. My preference is to table the
package name voting until the future time that we are closer to
need to pick a TCK package name. Personally, I would prefer to
not have `ee.jakarta` in the standard package name because of the
existing use of `ee` in Platform TCK test packages (for several
Regarding TCKs that currently use the `jakarta` package name, IMO
further discussion is needed to be sure that we address concerns
raised by Lukas for TCK tests that may need to use the `jakarta`
namespace in the future before we ban TCK tests that use `jakarta`
package. In summary, if Lukas as SPEC API lead, needs a special
TCK test that uses the `jakarta` namespace to test a specific
condition, he would be allowed to do that until such a time that
the SPEC committee bans such validation being done by TCKs.
Regarding EE 10 and making progress forward on TCKs, IMO, it seems the short term objective could be to suggest some possible package names that avoid using the `jakarta` namespace but take the stance that SPEC API projects will pick the right TCK package name. IMO, this allows EE 10 development to resume and the few TCKs that are using the `jakarta` namespace, to pick a new package (perhaps from our suggested package names).
Reminder, there are teams that have been waiting to do renames on TCK tests for the last two weeks. They are simply awaiting our guidance to proceed. -David _______________________________________________ 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