| Re: [jakartaee-platform-dev] [jaxrs-dev] [External] : Re: Jakarta TCK package naming convention |
@Jan: commented inline but overall I think what you are stating is not accurate.
Le lun. 24 janv. 2022 à 10:36, Jan Westerkamp <jan.westerkamp@xxxxxxx> a écrit :
Romain,
regarding your short story:
I think this is a misinterpretation of the spec by you (and others):
Applications can and in some cases are allowed to use the jakarta.* namespace (or javax.*), especially TCKs are for the last! And this is for very good reason, too (Lukas explained that in detail).
Well, it is explicitly forbidden since at least 10 years but if you can see a paragraph saying the opposite - meaning the spec contradicts itself (happens sadly) - it could be refined.It was also respected by the TCK until the javax->jakarta migration missed this point in a "too fast" migration.
It is not - for good reasons:
Regarding common applications, your are not allowed to use i.e. because of the trademark, naming conflicts etc. Instead developers should use a namespace reflecting their project organisation.
But i.e. the TCK is allowed to use it!
And for common applications the user is allowed to add jakarta.* stuff too - i.e. to add jakarta specs, that are not included in the implementation already.
Filtering misconfigured user applications (by adding components
already provided by the implementation) to run them is not a good
reason for filtering the hole root namespace.
(OpenLiberty ?)
At the moment there is only one platform implementation mentioned in the threads (TomEE), that has problems with that (please add more):
No, all servers do it, even "subservers" (partial support of EE like Tomcat) and even libs (all JPA implementations for ex).The scope is globally "if there is any work with proxying and classloader" so it covers most of the implementations even if some can be fully contextual theorically - but I know none doing it this way.
TomEE
Yes, you can! (see above)
The following component spec implementations are mentioned to might have problems (please add more):
EclipseLink
CXF
OpenWebBeans
The original decision was made to split the TCK into parts, that fit into the spec project - therefore I strongly recommend to drop it in jakarta.[spec].* (some ? put it in jakarta.[spec].tck.*), where it belongs to.
As explained you cant start with jakarta so decision is more about what you put before, not what you put after which is already done and does not need to involve more work.
Best,Jan
Am 22.01.22 um 13:13 schrieb Romain Manni-Bucau:
Hi Markus,
The references and explanations are higher - at the beginning - in this thread. Long story short: platform assumes api package is not provided by the apps so tck simulating an app must not use it by spec.
Le sam. 22 janv. 2022 à 11:50, Markus Karg <markus@xxxxxxxxxxxxxxx> a écrit :
_______________________________________________Can you please publish that rule on a place that we can link to?
Also it would be great to hear why it is forbidden for us to stick with jakarta.* for TCK tests.
-Markus
Von: jakartaee-platform-dev [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] Im Auftrag von David Blevins
Gesendet: Freitag, 21. Januar 2022 23:26
An: jakartaee-platform developer discussions
Cc: jsonb-dev@xxxxxxxxxxx; jakartaee-tck-dev@xxxxxxxxxxx; jaxrs developer discussions; jsonp developer discussions
Betreff: Re: [jakartaee-platform-dev] [jaxrs-dev] [External] : Re: Jakarta TCK package naming convention
The LJC is the current elected Participant Member of the Specification Committee and voted +1. Of the binding votes from members of the Specification Committee who did not abstain, the vote did pass by super majority.
Using that namespace is still optional, however. The only requirement is not to use jakarta.* for TCK tests.
On Jan 21, 2022, at 2:12 PM, Markus Karg <markus@xxxxxxxxxxxxxxx> wrote:
I cannot see that a concensus was actually found. iJUG is voting against this decision.
-Markus Karg
iJUG Vice Embassador at Eclipse Foundation
Von: jaxrs-dev [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] Im Auftrag von Emily Jiang via jaxrs-dev
Gesendet: Dienstag, 18. Januar 2022 19:39
An: jakartaee-platform developer discussions
Cc: Emily Jiang; jsonp developer discussions; Scott Stark; jakartaee-tck-dev@xxxxxxxxxxx; jaxrs developer discussions; jsonb-dev@xxxxxxxxxxx
Betreff: Re: [jaxrs-dev] [jakartaee-platform-dev] [External] : Re: Jakarta TCK package naming convention
Just provide a quick update on this thread. We discussed the TCK namespace again at today's Jakarta Platform call. The conclusion for the tck namespace is as follows.
o General agreement that ‘jakarta’ namespace (starting with ‘jakarta’) must be avoided in EE10 TCKs
o Any non-’jakarta’ namespace is ok for EE10
p.s. I started a vote to get one TCK package namespace (ee.jakarta.tck.[spec]) approved by the Jakarta spec committee, which will be concluded tomorrow. I will share the result then. If that package name is approved, it can be used to replace the jakarta.* in EE 10 TCKs.
Thanks
Emily
On Fri, Jan 14, 2022 at 11:31 AM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:
Hi Scott,
Thanks for sharing your thoughts! You are heard:o. I see you have concerns with the new package of ee.jakarta.tck.[spec]. From my understanding, ee.jakarta is trying to say Jakarta EE. Jakarta EE includes the part of SE e.g. Jakarta CDI is under Jakarta EE but it also contains the part CDI SE, When it comes to names, it is almost impossible to make everyone happy. It is like people's names. Different people might have different opinions towards a particular name. If we clearly document ee.jakarta means Jakarta EE and it carries no other meaning, it might clarify some doubts.
What do other people think?
Thanks
Emily
On Thu, Jan 13, 2022 at 12:17 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
On Thu, Jan 13, 2022, 6:28 AM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:
Hi Scott,
The name change impacts the new tests starting with jakarta.* (polls were used to figure out a name). The overall TCK buckets should not be affected. As for the voting schedule, it was suggested on the mailing list but no one objected. Besides, we need to come to a quick conclusion due to the Jakarta EE 10 train, so the survey was shorter than others.
Hi Emily,
People were still trying to be heard that seemed to be ignored during the discussion.
Also the vote ended before we reached a conclusion on which problem needs to be solved.
I agree that this mostly impacts new Standalone TCKs but IMO the most popular choice doesn't sound right appropriate for Standalone TCKs that test both SE + EE. :(
Anyway, do you agree that TCKs only should avoid using jakarta as the initial package prefix?
I'm not personally against picking a standard TCK package name prefix for new TCK tests.
One possible package name prefix could be <spec>.tck but I am sure there other options like the ones you mentioned that don't have EE in them that could be meaningful for both SE + EE.
Thanks for listening to my feedback :)
Scott
Thanks
Emily
L
On Thu, Jan 13, 2022 at 9:44 AM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
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
On Wed, Jan 12, 2022, 5:06 PM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:
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
On Wed, Jan 12, 2022 at 10:00 PM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:
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
On Tue, Jan 11, 2022 at 9:38 PM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:
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 Tue, Jan 11, 2022 at 7:51 PM Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:
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$> |
>>> <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
--Thanks
Emily
--
Thanks
Emily
--
Thanks
Emily
--
Thanks
Emily
--Thanks
Emily
--Thanks
Emily_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev