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
The reference is at least in servlet spec as referenced earlier (at least https://jakarta.ee/specifications/servlet/5.0/jakarta-servlet-spec-5.0.html#web-application-class-loader) but https://jakarta.ee/specifications/platform/9.1/jakarta-platform-spec-9.1.html#a3046 (must part) also implies it even if not stated explicitly ("Components in the web container must have access to the following classes and resources" + "The Jakarta EE API classes specified in Jakarta EE Technologies for the web container." + the fact spec define their package as "jakarta.<spec>.*" = the jakarta classes are loaded from the "container" so skipped from the application).
Once again, there are technical reasons for this requirements and why it appeared in very early JavaEE times so don't think we should loose time discussing if it should be but we should more see how we handle the coming release and the fact current TCK are not compatible with this strong requirement.

I don't have any strong preference for the solution (1. release and ignore TCK until they are fixed ASAP after the release 2. have 1-2 people in task force mode to do the migration in a few days, 3. others) but it should be addressed - to be honest I didn't expect such a thread on that simple topic :(.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book


Le mar. 11 janv. 2022 à 10:43, Scott Marlow <smarlow@xxxxxxxxxx> a écrit :


On Tue, Jan 11, 2022, 2:53 AM Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote:
Well, since at least EE 5 - didnt check before - apps must not use the platform package (was javax, now it is jakarta).

Which platform spec section states the rule about applications not creating classes in the Jakarta package?  I looked in https://jakarta.ee/specifications/platform/9.1/jakarta-platform-spec-9.1.html but didn't find it.


If any tck uses jakarta package it is a miss/bug in the javax->jakarta migration but platform didn't change so it must still be done.

If there is stated requirement in the Platform spec for applications to not add Jakarta package classes, the TCKs should respect that but if there is no such requirement, then the discussion should shift to focus on applications.

Any automated tool can do it if you want.
The impact if you don't do is that a vendor not passing TCK can still claim to be certified since TCK are not compatible with the spec, wouldn't be that great right?

The Platform TCKs validate the Platform spec requirements.  As requested above, please provide section of Platform spec that requires that applications not create Jakarta namespace classes.

Scott


Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book


Le mar. 11 janv. 2022 à 01:03, Scott Marlow <smarlow@xxxxxxxxxx> a écrit :


On 1/10/22 5:04 PM, Dmitry Kornilov wrote:

I’m lost in this conversation and surprised that we are jumping to voting so fast.

The vote ballot as currently written is now for EE 11 only and for new TCKs being added to EE 11, which means the answer to the original question that initiated this discussion is that the Batch TCK does not need any changes (nor does other TCKs being added to EE 10).

I couldn’t find the driver for this change.

The driver was a question about packaging for the Jakarta Batch TCK.

I thought the discussion was jumping towards adding a Platform requirement for applications to not define classes in the "jakarta" namespace but we didn't seem to get there.  IMO, the time to make such an application restriction would of been for EE 9 (since making such a change for EE 10 or 11 would be a breaking change now, even if it has low likely impact on most applications).

I believe that less renaming is better for the platform. Renaming and especially renaming in TCKs is a big task. Who is going to do this? I am not ready to assign people to it. Last time we changed names for Maven artifacts we introduced the package split problems we still suffering with. So, if you ask me -> NO RENAMING!

IMO, if application classes are allowed to define classes in the jakarta namespace, than TCKs should also be allowed to do the same.  If we add a breaking Platform SPEC change to EE 10 or 11 to not allow applications to define classes in the jakarta namespace, TCKs should then be updated (new + existing) to follow that same rule. 

Scott

 

-- Dmitry

 

P.S.

Also, I don’t think that it’s up to the platform group to make this decision. TCKs are a part of specifications, so it must go through the spec committee to get approved.

 

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Emily Jiang via jakartaee-platform-dev
Sent: 10 January 2022 22:43
To: David Blevins <dblevins@xxxxxxxxxxxxx>
Cc: Emily Jiang <emijiang6@xxxxxxxxxxxxxx>; jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: [External] : Re: [jakartaee-platform-dev] Jakarta TCK package naming convention

 

Done. I thought from the conversation thread, the package name of org.jakartatck.* might have some complications. Anyway, I have added.

Thanks

Emily

 

On Mon, Jan 10, 2022 at 6:20 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:

Can we add the org.jakartatck option to this?

 

-David

 

 

On Mon, Jan 10, 2022 at 9:21 AM emijiang6--- via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Google Forms

 

Having trouble viewing or submitting this form?

Fill out in Google Forms

 

I've invited you to fill out a form:

Jakarta TCK package naming convention

For all new Jakarta TCKs, we need a naming convention. All TCKs for Jakarta EE 10, the requirement is not to use jakarta.*. From Jakarta EE 11, the naming convention must be used.

The new Jakarta EE TCKs from Jakarta EE 11 must use the following naming convention. Pick your choice below.

    • ( ) ee.jakarta.tck.[spec]
    • ( ) tck.jakarta.[spec]
    • ( ) org.eclipse.jakarta.tck.[spec]

[Submit]

Powered by

Google Forms

 

This content is neither created nor endorsed by Google.
Report Abuse - Terms of Service - Additional Terms

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

--

Sent from Gmail Mobile



--

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
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

Back to the top