Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [External] : Re: Jakarta TCK package naming convention

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$



Back to the top