In summary, we should avoid using Jakarta as the first prefix in the package name of certain non spec api classes like TCKs. The reason being that some EE implementations may be filtering spec api classes by simply checking for "jakarta.*" classes as part of application deployment processing.
I'm still unsure of the EE 10 schedule cost for this change. I suggest that we make the package change after other TCK changes are merged so that there is less delay caused by this change (e.g. goal being to minimize breaking other in progress TCK work).
In future community polls, we should allow more time for input so that more community users can participate.
I'm not sure if the choice to use ee.jakarta.tck.[spec] will help any Standalone TCKs but if yes, you now have the option to use it. Historically, we use EE for Jakarta EE TCK tests but not consistently, even less consistently now since all newly added tests might start with EE.
Hope this helps,
Scott
Thank you all for who have voted! Survey result from the community for the TCK package names is as follows.
29 responses:
package name: votes
==================
ee.jakarta.tck.[spec]: 14
tck.jakarta.[spec]: 7
org.eclipse.jakarta.tck.[spec]: 8
org.jakartatck.[spec]: 0
The clear winner is ee.jakarta.tck.[spec]. The NEW Jakarta TCKs in Jakarta EE 10 can start adopting this package name if their current package names are jakarta.*.
To make this vote formal, I was asked to start a ballot on the Spec committee to get this community-chosen package name ee.jakarta.tck.* formally approved by the committee. I'll start that process momentarily.
Thanks
Emily
Thank you all for who have voted! Survey result from the community for the TCK package names is as follows.
29 responses:
package name: votes
==================
ee.jakarta.tck.[spec]: 14
tck.jakarta.[spec]: 7
org.eclipse.jakarta.tck.[spec]: 8
org.jakartatck.[spec]: 0
The clear winner is ee.jakarta.tck.[spec]. The NEW Jakarta TCKs in Jakarta EE 10 can start adopting this package name if their current package names are jakarta.*.
To make this vote formal, I was asked to start a ballot on the Spec committee to get this community-chosen package name ee.jakarta.tck.* formally approved by the committee. I'll start that process momentarily.
Thanks
Emily
Hi Lukas,
Do we know how long one needs to wait to get recommended package name OR
is it expected that the project teams choose something and repeat the
exercise for EE 11 once the recommendation/requirement is in place?
The
vote will be closed on 9:21am Pacific Wednesday 12th Jan. You can find the current response
here. You can already see the potential winner there. By the way, if you choose something not starting with jakarta.*, you can stick to it for future releases. The new naming convention applies to the new TCKs from Jakarta EE 11 onwards. Any existing TCKs are not required to be updated.
Thanks
Emily
On 1/11/22 7:51 PM, Scott Marlow wrote:
>
> On 1/11/22 1:04 PM, Scott Stark wrote:
>> The issue for EE10 is if TCKs are delivering application deployments
>> under the jakarta.* package namespace, which implementation will
>> challenge this as invalid?
>>
>> Historically (Jakarta EE 9 and earlier), tck deployments were under a
>> vendor specific package namespace, com.sun.*, org.jboss.*, etc.
>>
>> The short term issue is whether the use of jakarta.* package
>> deployments is going to cause problems with getting sufficient
>> compatible implementations certified.
>
> https://github.com/eclipse-ee4j/jaxrs-api/issues/1081 asks for input on
> the schedule impact of changing the new RESTful Web Services TCK tests
> from jakarta package to something that doesn't start with the jakarta
> package.
>
> I'm curious what the schedule impact would be for the new JSON Binding +
> JSON Processing TCKs to not use the jakarta package name in test classes?
If you ask me and assuming current target (end of Feb), then from the
high level perspective, there are still about 6 weeks to do the work
which looks fine, even though it is not clear to what exactly the
package is expected to be changed yet. Just keep in mind that those who
are expected to do the work are supposed to handle other projects
(specs, impls, TCKs) as well, so more time they spend on this, less time
they'll have for other stuff and that other stuff may not meet the
currently defined deadline.
Do we know how long one needs to wait to get recommended package name OR
is it expected that the project teams choose something and repeat the
exercise for EE 11 once the recommendation/requirement is in place?
thanks,
--lukas
>
> Scott
>>
>>
>> On Jan 11, 2022 at 6:28:25 AM, Romain Manni-Bucau
>> <rmannibucau@xxxxxxxxx> wrote:
>>> I can agree with all you said but still the problem is there so
>>> conclusion is still TCK must change of packaging at some point.
>>> So discussion points are:
>>>
>>> 1. when
>>> 2. how to mitigate next release certification if 1 is after next release
>>> 3. which package
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> <https://urldefense.com/v3/__https://twitter.com/rmannibucau__;!!ACWV5N9M2RV99hQ!fos1sjDRXC7c7ttwcR9-SuXqknQp-7MecLj6f9lfpCH8vS_koSV3USrIrLZJcpM0YTU$>
>>> | Blog
>>> <https://urldefense.com/v3/__https://rmannibucau.metawerx.net/__;!!ACWV5N9M2RV99hQ!fos1sjDRXC7c7ttwcR9-SuXqknQp-7MecLj6f9lfpCH8vS_koSV3USrIrLZJeOaq3W8$> |
>>> Old Blog
>>> <https://urldefense.com/v3/__http://rmannibucau.wordpress.com__;!!ACWV5N9M2RV99hQ!fos1sjDRXC7c7ttwcR9-SuXqknQp-7MecLj6f9lfpCH8vS_koSV3USrIrLZJ-r8kkFQ$>
>>> | Github
>>> <https://urldefense.com/v3/__https://github.com/rmannibucau__;!!ACWV5N9M2RV99hQ!fos1sjDRXC7c7ttwcR9-SuXqknQp-7MecLj6f9lfpCH8vS_koSV3USrIrLZJrAnLuVE$> |
>>> LinkedIn
>>> <https://urldefense.com/v3/__https://www.linkedin.com/in/rmannibucau__;!!ACWV5N9M2RV99hQ!fos1sjDRXC7c7ttwcR9-SuXqknQp-7MecLj6f9lfpCH8vS_koSV3USrIrLZJ4gPkq8o$> |
>>> Book
>>> <https://urldefense.com/v3/__https://www.packtpub.com/application-development/java-ee-8-high-performance__;!!ACWV5N9M2RV99hQ!fos1sjDRXC7c7ttwcR9-SuXqknQp-7MecLj6f9lfpCH8vS_koSV3USrIrLZJecqVzg0$>
>>>
>>>
>>> Le mar. 11 janv. 2022 à 13:19, Lukas Jungmann
>>> <lukas.jungmann@xxxxxxxxxx> a écrit :
>>>
>>> On 1/11/22 12:21 PM, Romain Manni-Bucau wrote:
>>> >
>>> >
>>> >
>>> > Le mar. 11 janv. 2022 à 11:28, Lukas Jungmann
>>> <lukas.jungmann@xxxxxxxxxx
>>> > <mailto:lukas.jungmann@xxxxxxxxxx>> a écrit :
>>> >
>>> > to me "should not" != "must not" based on RFC 2119/8174; a
>>> > recommendation is not a requirement per se. But it's
>>> evident I'm still
>>> > missing something.
>>> >
>>> >
>>> > Right _for servlet part_, but what does it change?
>>> > Well, read it as it is "implementations should do", they can or
>>> not as
>>> > you point out but they are highly encourage to, so TCK must
>>> assume they
>>> > do, so we didn't move forward AFAIK.
>>>
>>> TCKs must be able to handle both cases as both are valid based on
>>> the
>>> current wording. They are not the ones to assume anything, they
>>> are the
>>> ones to expect things to happen or not to happen based on current
>>> definitions. Ideally, TCKs only follow changes in definitions,
>>> not the
>>> other way around.
>>>
>>> Also note that there is a difference between "Jakarta classes" and
>>> "Jakarta Platform classes" and this differentiation should be kept.
>>> Currently, MVC, NoSQL or even some TCKs are "Jakarta classes" but
>>> not
>>> "Jakarta Platform classes" (given both groups are using jakarta
>>> package
>>> namespace).
>>>
>>>
>>> --lukas
>>>
>>
>> _______________________________________________
>> jakartaee-platform-dev mailing list
>> jakartaee-platform-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!fos1sjDRXC7c7ttwcR9-SuXqknQp-7MecLj6f9lfpCH8vS_koSV3USrIrLZJSw1XQBU$
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
--
--
