[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] Standardizing new TCK packages (was:package prefixes for Jakarta Batch TCK-related classes?org.eclipse.ee4j.batch ?)
|
Emily,To answer your
question, it's an existing TCK that we are porting from the platform into
the the particular spec project where we are also adding new test cases
to cover the function that is new in EE 10. The developer working
on the TCK port overachieved and had renamed the packages from whatever
they were previously to jakarta.*, and then others of us when adding new
tests used the same package to match the ported tests. To reiterate
what stated in my reply, this is not going to be a concern for TomEE and
others because I'm agreeing to get the TCK off of the jakarta.* packages
for EE 10 - just not to wait for the outcome of what will be the new convention
because that would set us back too far. Given the number of positive
replies to that, I already have a pull in place to do so and have notified
several other spec participants who have new TCK tests that they are writing
currently in progress so that can use a different package. I appreciate
the quick replies from everyone - this is a case where being able to take
decisive action right away definitely lessens the impact.From:
"Romain
Manni-Bucau" <rmannibucau@xxxxxxxxx>To:
"jakartaee-platform
developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>Date:
01/06/2022
12:18 PMSubject:
[EXTERNAL]
Re: [jakartaee-platform-dev] Standardizing new TCK packages (was:package
prefixes for Jakarta Batch TCK-related classes?org.eclipse.ee4j.batch ?)Sent
by: "jakartaee-platform-dev"
<jakartaee-platform-dev-bounces@xxxxxxxxxxx>
Just want to remind we don't speak about
some issue with implementations - typically TomEE has a "toggle"
to solve it - but with the spec which forbids it so it means that using
jakarta.tck is forbidden by jakarta as quote earlier, in particular cause
most of TCK are ran in servlet context by the TCK runner and it had been
like that since years, I just think javax -> jakarta (and more likely
sun -> eclipse) move missed that.So no choice to rename, it seems the
options are:* jakarta.ee- from my point of view it comes from nowhere for anyone not deeply involved
in Jakarta,* tck.jakarta - not very neat but works* org.eclipse.jakarta.tck - I still think
it is the most consistent with what Jakarta is as of today.Agree existing spec (using org.jboss
for ex) don't need to move now, the only requirement is to not use jakarta.something
for anything which is actually deployed as an application.
Romain Manni-Bucau
@rmannibucau| Blog |
Old
Blog | Github |
LinkedIn |
BookLe jeu. 6 janv. 2022 à 18:50,
Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
a écrit :Nathan,Which Jakarta spec tcks already used
this package starting with jakarta.*? Is this change new for Jakarta EE
10 or already released in the earlier Jakarta EE release? If it was released
before, then it is not an issue. If it is a new change, will this be a
concern for TomEE as mentioned by David? When TomEE (might be others) comes to
run the tck, it might cause issues. David, any thoughts on this? If it
is the case, it might be ok to choose a different package such as ee.jakarta
or jakartatck etc. By the way, the new naming convention
is for new specs. The existing specs should adopt it in the subsequent
release EE 11 once we have reached agreement on which name to use.ThanksEmilyOn Thu, Jan 6, 2022 at 3:41 PM Nathan
Rauh <nathan.rauh@xxxxxxxxxx>
wrote:This discussion
is concerning because one of the Jakarta specs that I'm working on and
which is already cutting it too close making the EE 10 release is unfortunately
using jakarta.* package names for TCK classes, and now it's going to need
to change, further compromising our chances of getting into EE 10.
The chosen package name doesn't matter to me, nor does whether or not there
is standardization across TCKs. What does matter (to this spec at
least) is getting a decision made quickly, but I don't foresee a decision
on this being reached anytime soon given the many widely varying opinions
that will likely eventually become a vote, itself with a sufficient period
of time for votes to be collected and all of that. It's just way
too late into EE 10 for adding a new requirement like this, and I'm going
to suggest that it apply to EE 11 instead, with the understanding that
for EE 10, we'll at least get off of the jakarta.* package name in the
tck to something else and then align with whatever you decide in EE 11.
Unless anyone objects, that's what I'll plan on doing.
From: "Werner
Keil" <werner.keil@xxxxxxx>
To: "jakartaee-platform
developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 01/06/2022
09:20 AM
Subject: [EXTERNAL]
Re: [jakartaee-platform-dev] Standardizing new TCK packages (was:package
prefixes for Jakarta Batch TCK-related classes?org.eclipse.ee4j.batch ?)
Sent by: "jakartaee-platform-dev"
<jakartaee-platform-dev-bounces@xxxxxxxxxxx>
At
least org.glassfish still seems to be used.
Werner
Gesendet
von Mailfür
Windows
Von:
Mike
Milinkovich
Gesendet: Donnerstag, 6. Januar 2022 15:24
An: jakartaee-platform-dev@xxxxxxxxxxx
Betreff: Re: [jakartaee-platform-dev] Standardizing new TCK packages
(was:package prefixes for Jakarta Batch TCK-related classes?org.eclipse.ee4j.batch
?)
I would like to point out that we do not use "org" anywhere with
Jakarta at the moment. We do not own the jakarta.orgdomain name, for example. We do own and use the jakarta.eedomain 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 fororg.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
From: "Emily
Jiang via jakartaee-platform-dev" <jakartaee-platform-dev@xxxxxxxxxxx>
To: "jakartaee-platform
developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: "Emily Jiang"
<emijiang6@xxxxxxxxxxxxxx>
Date: 01/06/2022
05:16 AM
Subject: [EXTERNAL]
Re: [jakartaee-platform-dev] Standardizing new TCK packages (was: package
prefixes for Jakarta Batch TCK-related classes? org.eclipse.ee4j.batch
?)
Sent by: "jakartaee-platform-dev"
<jakartaee-platform-dev-bounces@xxxxxxxxxxx>
Thank you David for the detailed explanation! I now understood the concern.
The following package name might work:
-- tck.jakarta.<spec>.
In all, we could choose one from the list
org.jakartatck.*
ee.jakarta.tck.*
tck.jakarta.*
Thanks
Emily
On Thu, Jan 6, 2022 at 12:09 AM David Blevins <dblevins@xxxxxxxxxxxxx>
wrote:
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.
- https://github.com/eclipse-ee4j/eclipselink/blame/master/jpa/org.eclipse.persistence.jpa/src/main/java/org/eclipse/persistence/internal/jpa/deployment/JavaSECMPInitializer.java#L345
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.eedomain
and can potentially use either of these:
- ee.jakarta.*
- ee.jakarta.tck.*
I also just looked and jakartatck.orgwas
available, so I purchased that and we could potentially use:
- org.jakartatck.*
If we wanted to go that direction, I'd just transfer jakartatck.orgto
the Working Group like I did when purchased jakarta.ee.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> 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
_______________________________________________
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
_______________________________________________
jakartaee-platform-dev
mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To
unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
Mike
Milinkovich
Executive
Director | Eclipse
Foundation AISBL
Twitter:@mmilinkov
| This
email has been checked for viruses by Avast antivirus software. www.avast.com |
[attachment
"graycol.gif" deleted by Nathan Rauh/Rochester/IBM] _______________________________________________
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_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev