[
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 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.
thanks,
--lukas
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 https://www.eclipse.org/lists/eclipselink-dev/msg08208.html
<https://urldefense.com/v3/__https://www.eclipse.org/lists/eclipselink-dev/msg08208.html__;!!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.
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$
<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 <mailto: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$
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec__;!!ACWV5N9M2RV99hQ!cAMOYrqf80eHdwv5hFz3XAn7oo3MYZOaulN0FUGj7hTFbXhChW6G8mspe-JcR-_dwLE$>
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx <mailto:jakarta.ee-spec@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec__;!!ACWV5N9M2RV99hQ!fYfQBphkHk-n4YHKYN6W3UOT-s-QNwPJ4M9fwpEiLo2CEZp0P5NC5YAALvWedo3Otw0$>
_______________________________________________
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!fYfQBphkHk-n4YHKYN6W3UOT-s-QNwPJ4M9fwpEiLo2CEZp0P5NC5YAALvWedo3Otw0$
