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 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.

The long term issue is whether the use of the same root as the specification APIs is the right thing to be doing. In terms of simple filtering of application deployments I would say no.


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 |  Blog | Old BlogGithub | LinkedIn | Book


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


Back to the top