Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec] [External] : [BALLOT] Revised: Recommend naming convention for new TCK tests in Jakarta EE 10 - Ends Jan 26th, 6pm Pacific 
On 1/20/22 3:00 AM, David Blevins wrote:

  - 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.
With my EclipseLink project project lead hat on: This is a bug in EclipseLink and a project should file a TCK challenge/bug against XML Binding Specification TCK to add a test covering applications written in jakarta package namespace. Jakarta XML Web Services Specification API is an example of the XML Binding application written in jakarta package namespace - as of Jakarta EE 9.x. 
(see also https://www.eclipse.org/lists/eclipselink-dev/msg08208.html)




  - 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.*
With my XML Web Services specification project lead hat on: Is the same (legal?) restriction applicable to Jakarta Specification projects? Is there a distinction between "Application developers" and "Jakarta Specification APIs developers"? If so, would it make sense to define clear border between these two groups of developers? 



  - 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.
With my EclipseLink project lead and Eclipse Implementation of JAXB project lead hats on (both are CIs of the XML Binding specification): we argue that the TCK for the XML Binding Specification should provide better coverage for applications written in the jakarta package namespace. Complete exclusion of the jakarta package namespace from TCK will lead to less test coverage for integrations between various Jakarta Specification projects. 


thanks,
--lukas




Please use the this thread if you'd like to discuss/challenge the above: https://urldefense.com/v3/__https://www.eclipse.org/lists/jakartaee-platform-dev/msg03014.html__;!!ACWV5N9M2RV99hQ!cAMOYrqf80eHdwv5hFz3XAn7oo3MYZOaulN0FUGj7hTFbXhChW6G8mspe-JcMuQDk5w$

# 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.


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://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec__;!!ACWV5N9M2RV99hQ!cAMOYrqf80eHdwv5hFz3XAn7oo3MYZOaulN0FUGj7hTFbXhChW6G8mspe-JcR-_dwLE$

Back to the top