I would like to point out that we do not use "org" anywhere with
Jakarta at the moment. We do not own the jakarta.org domain name,
for example. We do own and use the jakarta.ee domain name.
From my perspective, starting to use the .org TLD with Jakarta
for this purpose might be confusing.
On 2022-01-06 9:09 a.m., Scott Kurz
wrote:
+1 for org.jakartatck.*
(though OK with the other
options)
Thanks David for making that an
option and thanks all for giving this some thought. Even though not too many people
look at a TCK relatively speaking it seemed better to be good
Java citizens and use a package of a domain name we own.
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience skurz@xxxxxxxxxx
--------------------------------------------------------
"Emily
Jiang via jakartaee-platform-dev" ---01/06/2022 05:16:41
AM---Thank you David for the detailed explanation! I now
understood the concern. The following package na
I think I finally see what Romain is
talking about.
I know in TomEE we have several optimizations to try and speed
up deployment and bytecode scanning. We'll filter out jars
that match patterns like log4j-*, openejb-*, jakarta-*. Those
jars are removed from the list of jars that could potentially
contain applications and they'll never be searched for
annotations like @Singleton, etc. Additionally, as everyone
uses somewhat expensive bytecode readers like ASM to parse
bytecode and scan for annotations, we have additional filters
to skip non-application classes, such as javax.* and
jakarta.*. There are classloader related actions as well.
Here's an example we hit in EclipseLink when we tried to use
the Eclipse Transformer to do the javax-to-jakarta change.
We were transforming EclipseLink 2.x which did not have the
`!name.startsWith("jakarta.")` string check, so jakarta.*
classes were getting loaded as application classes and causing
most tests to fail. We hit this in a few different libraries
and ended up having to patch source to ensure "jakarta." and
"Ljakarta/" were factored into any code that checked for
"javax." as a package or "Ljavax/" as bytecode.
If we started putting the TCK tests in "jakarta.tck" and that
also included the test applications we need to deploy and
verify, that definitely will cause issues in a handful of
component implementations we all use.
The only way to handle it would be to update code like this to
have an exclusion that explicitly checks for "jakarta.tck" and
ensures it is treated as user-created application code and
bypasses any "javax" or "jakarta" checks. That's going to
mean there'll be code in our implementations that says
essentially "if your code starts with jakarta.tck, make sure
it's treated correctly, otherwise do something else." That
could be a slippery slope.
It's probably better if we don't put ourselves in a situation
were we have to write code to specially handle TCK
applications.
It occurs to be in writing this that literally any characters
before "jakarta" solves this issue. If we want a short name,
we do own the jakarta.ee domain and can potentially use either
of these:
- ee.jakarta.*
- ee.jakarta.tck.*
I also just looked and jakartatck.org was available, so I purchased that and
we could potentially use:
- org.jakartatck.*
If we wanted to go that direction, I'd just transfer jakartatck.org to the Working Group like I did when
purchased jakarta.ee.
> On Jan 5, 2022, at 1:19 PM, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:
>
> Just to make sure I understand you. Are you suggesting
that an application class loader for the old Java EE (e.g.
Java EE 8) must not allow not allow an application (WAR) to
package and load any classes from javax.* which they contain.
For example, no application server should allow an application
to contain and successfully load javax.foo.Bar? And now that
we are in the jakarta.* namespace no application server should
allow an application to package and load a jakarta.foo.Bar
class? What about javax now that we are jakarta, can
applications in Jakarta 9 now successfully include and load
javax.foo.Bar?
>
> I have to say this is news to me, and I do not believe
that is the way most application servers behave.
>
> Tom
>
>
>
> ----- Original message -----
> From: "Romain Manni-Bucau" <rmannibucau@xxxxxxxxx>
> Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
> To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
> Cc:
> Subject: [EXTERNAL] Re: [jakartaee-platform-dev]
Standardizing new TCK packages (was: package prefixes for
Jakarta Batch TCK-related classes? org.eclipse.ee4j.batch ?)
> Date: Wed, Jan 5, 2022 2:09 PM
>
>
> Le mer. 5 janv. 2022 à 20:37, Thomas Watson <tjwatson@xxxxxxxxxx> a écrit :
> > If you want one example, servlet 10.7.2 (for v4.0 to
take one example) explicit it and for good technical reasons
so it is a "must stay" but it implies TCK shouldn't reuse the
same package by design and as it always had been so it let you
org.eclipse for projects without an historical package (guess
it is more than fine to keep the existing one when it is
there).
>
> In no way do I see how that section of the v4.0 servlet
spec says anything about jakarta.*. That package didn't exist
in v4. For v5 we have: https://jakarta.ee/specifications/servlet/5.0/jakarta-servlet-spec-5.0.html#web-application-class-loader
>
> Here I think you are referring to this sentence:
>
> "Servlet containers that are not part of a Jakarta EE
product should not allow the application to override Jakarta
EE platform classes, such as those in the jakarta.*
namespaces, that Jakarta EE does not allow to be modified."
>
> TCK classes are not considered platform classes, they are
TCK classes. I don't see how this sentence applies to a
possible jakarta.tck package.
>
>
> This is true for part of the tck but most of them are
*applications* (servlet for a trivial example, everything in
war/ear for another one).
> Just stated what we have and do - and to be honest it is
normal otherwise tck wouldnt validate compliance using a
custom packaging ;).
>
>
> Tom
>
>
>
> ----- Original message -----
> From: "Romain Manni-Bucau" <rmannibucau@xxxxxxxxx>
> Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
> To: "Emily Jiang" <emijiang6@xxxxxxxxxxxxxx>
> Cc: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
> Subject: [EXTERNAL] Re: [jakartaee-platform-dev]
Standardizing new TCK packages (was: package prefixes for
Jakarta Batch TCK-related classes? org.eclipse.ee4j.batch ?)
> Date: Wed, Jan 5, 2022 10:09 AM
>
>
>
> Le mer. 5 janv. 2022 à 16:37, Emily Jiang <emijiang6@xxxxxxxxxxxxxx> a écrit :
> @Romain Manni-Bucau
> I must have misunderstood your question. Let me try
again to clarify this:
> 1. what's the plan about the spec saying jakarta.* should
be excluded from the applications (which means it cant be used
by TCK)?
> I disagree with what you said jakarta.* can't be used by
TCK because TCKs are part of specs and do not fall into the
application category. Besides, can you point out which spec
has this sentence? We need to discuss this further to see
whether it is correct to say so if it does have this sentence.
>
> Ok so the consequence of you statement is that there is
no application code in TCK, no CDI bean, no EJB, no servlet,
no JSP etc... (which is not true right?) so TCK are mainly a)
application code and b) test code (sometimes c) runner code
but let's integrate it in b)).
>
> If you want one example, servlet 10.7.2 (for v4.0 to take
one example) explicit it and for good technical reasons so it
is a "must stay" but it implies TCK shouldn't reuse the same
package by design and as it always had been so it let you
org.eclipse for projects without an historical package (guess
it is more than fine to keep the existing one when it is
there).
>
>
> 2. What about user confusion? "not care" :(?
> Not sure what user confusion do you mean? TCKs are pretty
much for implementers. Besides, I am not sure what confusions
you are referring to. I think the namespace with jakarta.tck
is clearer as it means the tck classes from Jakarta.
>
> As soon as you get the dependency in a dependency - you
are an user by definition - then you can get issues if you use
jakarta.
> It is also the case for end user - who never use tck
package - on maven if they are released under jakarta groupId
so as recommended in java ecosystem the groupId should be
aligned on the package base name so likely use
org.eclipse.jakarta.spec or alike. The risk is users start
importing tck instead of the spec and application will work
cause the spec comes transitively but it is not what jakarta
wants, right? Making it clean is trivial and consistent with
everything so I think it is worth not trying to be more clever
than we need to.
>
> HTH
>
>
>
> On Wed, Jan 5, 2022 at 3:02 PM Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote:
> @Emily: i know TCK are part of the spec as well as the
API, javadoc and textual doc (pdf/word) but you didn't solve
the 2 issues I mentionned (not even speaking of the
inconsistency between the status and naming which is something
very few will care except eclipse itself maybe) so not sure
how the fact it is delivered as a whole solves the fact it is
forbidden by spec to use this package.
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn |
Book
>
> Le mer. 5 janv. 2022 à 15:26, Emily Jiang <emijiang6@xxxxxxxxxxxxxx> a écrit :
> Romain,
> TCKs are part of spec, as spec includes api/spec doc
/tck.
> Thanks
> Emily
>
> On Wed, Jan 5, 2022 at 1:48 PM Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote:
> @Emily: what's the plan about the spec saying jakarta.*
should be excluded from the applications (which means it cant
be used by TCK)? What about user confusion? "not care" :(?
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn |
Book
>
> Le mer. 5 janv. 2022 à 14:31, Emily Jiang via
jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> a écrit :
> We discussed the various package names including
org.eclipse.*. The feedback is that TCKs should align with the
corresponding spec. It is much nicer to start with jakarta.tck
to denote the TCK classes and also easily to filter out with
pattern matching when searching for api classes. Besides it is
much shorter than org.eclipse.jakarta.
> In Jakarta Batch Tcks, you will use jakarta.tck.batch
instead of org.eclipse.jakarta.tck.batch.
>
> Thanks
> Emily
>
> On Wed, Jan 5, 2022 at 8:05 AM Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote:
> As written on jbatch list I think it is normal and safe
to use org.eclipse.<something like jakarta.spec or just
spec> since jakarta specs are eclipse projects. It also has
the advantage to not use jakarta.* package which is treated
specifically by all implementations (by spec actually ;)) and
would need some specific rules in the impl is used for tcks
too which is not the target of the spec at all. Lastly it
makes it obvious it is not part of the API for users so it is
very good too. For me, it looks like a consistent and good
compromise for everyone (foundation, users, vendors and spec
contributors/legal).
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn |
Book
>
> Le mer. 5 janv. 2022 à 08:23, Jean-Louis Monteiro <jlmonteiro@xxxxxxxxxxxxx> a écrit :
> Sounds like a good improvement to me as well
>
> Le mar. 4 janv. 2022 à 22:00, David Blevins <dblevins@xxxxxxxxxxxxx> a écrit :
> > On Jan 4, 2022, at 12:23 PM, Emily Jiang via
jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
> >
> > I had this matter discussed in today's platform
call. Below is the suggestion for the naming convention:
> > • [Emily] Package naming convention for TCKs?
> > • Packages for TCK starts with various
names, e.g. org.ibm, org.jboss, org.eclipse,
jakarta.[spec].tck etc,
> > • Should they be standardized?
> >
> > • Two things need naming standard:
> > • Packages
> > • Suggested Naming Standard:
jakarta.tck.[spec]
> > • New classes in existing TCKs
should use the new name standard
> > • Artifacts
> > • Same group id as the spec
> > • Artifact ids [foo]-tck
> > • Existing TCKs may change if they like
> > New TCKs must use the new name standard
> >
> > The above is the general consensus from the meeting.
I will start a new thread conversation for others to comment
on the naming convention.
>
> Others can chime in, but I like the above
recommendation. Using jakarta.tck.[spec] is just as good as
org.eclipse.jakarta.tck.[spec], perhaps better.
>
> Also agree that it should be standard across the various
TCKs.
>
>
> -David
>
> _______________________________________________
> 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
>
>
> --
> 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
>
>
> --
> 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
>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev