Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] [External] : [BALLOT] Revised: Recommend naming convention for new TCK tests in Jakarta EE 10 - Ends Jan 26th, 6pm Pacific

On 1/20/22 7:03 PM, Scott Stark wrote:
I still don't understand why the jakarta namespace cannot be treated the same as the java.* and javax.* namespace with respect to filtering. Historically this code worked, so why is it now that it is a requirement that implementations have to process some jakarta.* namespaces?

it is likely that there will always be a CI of some Jakarta Specification which won't be able to filter out everything from jakarta package namespace, yet most will be probably able to do so. It should not be a requirement for all implementations to process all jakarta namespaces but the decision about what the particular implementation wants to process or skip should be left up to itself and/or a spec which defines it. This used to work in the past and if it does not work today - based on provided example - I do not understand why the solution is to "let's ban jakarta namespace" instead of "you have a bug, fix it". Former is simpler for everyone, but is it the right one?

Historically, most CIs (former RIs) of specifications directly included in JDK were not filtering out everything from javax package namespace, even GlassFish was not doing so to the certain extent (versions 3 and 4 at least, I think), and they cannot blindly do so even today with jakarta namespace, so from those projects' point of view saying that everything from the jakarta package namespace must/can be filtered out by CI is misleading based on what we have today.

With jakarta namespace, there is an opportunity to learn from the past, apply the knowledge gained over decades to the rules being defined and prepare them for the future, ie it wasn't true for the javax namespace in Java EE times that everything being developed in the javax package namespace is part of the Java EE Platform and the same is not/will not be true for the jakarta package namespace. That may be as simple as putting sth like "Package/module names that start with the identifier jakarta are reserved for packages of the Jakarta Specification Projects. These packages/modules are not subject to the requirements given on user applications." somewhere to be explicit about it and to not allow this to fall into grey area. Maybe it is already written somewhere and I just cannot find it.

With regard to the question on '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?', the answer is certainly yes, but that still leaves the question of how the TCK fits in. Specification projects are able to utilize the jakarta.* namespace for APIs. TCK test vehicle deployments are acting as if they are application developers to validate the expected behavior of implementations. As such, they should not be making use of API package namespaces.

Whatever wording allows inclusion of tests for integrations between various specifications in the TCK, very likely in the jakarta package namespace for those who needs it, is fine by me, assuming legal aspect of things allows that. I believe "should not" satisfies it.


On Jan 20, 2022 at 5:40:33 AM, Lukas Jungmann <lukas.jungmann@xxxxxxxxxx <mailto:lukas.jungmann@xxxxxxxxxx>> wrote:
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 <;!!ACWV5N9M2RV99hQ!fYfQBphkHk-n4YHKYN6W3UOT-s-QNwPJ4M9fwpEiLo2CEZp0P5NC5YAALvWekOg5DZM$>)

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


Please use the this thread if you'd like to discuss/challenge the above:;!!ACWV5N9M2RV99hQ!cAMOYrqf80eHdwv5hFz3XAn7oo3MYZOaulN0FUGj7hTFbXhChW6G8mspe-JcMuQDk5w$ <;!!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 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.


_______________________________________________ mailing list <>
To unsubscribe from this list, visit;!!ACWV5N9M2RV99hQ!cAMOYrqf80eHdwv5hFz3XAn7oo3MYZOaulN0FUGj7hTFbXhChW6G8mspe-JcR-_dwLE$ <;!!ACWV5N9M2RV99hQ!cAMOYrqf80eHdwv5hFz3XAn7oo3MYZOaulN0FUGj7hTFbXhChW6G8mspe-JcR-_dwLE$>

_______________________________________________ mailing list <>
To unsubscribe from this list, visit <;!!ACWV5N9M2RV99hQ!fYfQBphkHk-n4YHKYN6W3UOT-s-QNwPJ4M9fwpEiLo2CEZp0P5NC5YAALvWedo3Otw0$>

_______________________________________________ mailing list
To unsubscribe from this list, visit;!!ACWV5N9M2RV99hQ!fYfQBphkHk-n4YHKYN6W3UOT-s-QNwPJ4M9fwpEiLo2CEZp0P5NC5YAALvWedo3Otw0$

Back to the top