On Jan 6, 2022, at 9:26 AM, Thomas Watson
<tjwatson@xxxxxxxxxx <mailto:tjwatson@xxxxxxxxxx>> wrote:
Edicts and trademarks may be clear. What is not clear
is what an application classloader/scanning should do
when a customer application violates said edict or
trademark. If we have many of our implementations
defining some behavior based on this then I think it is
in our best interests to make it clear in the
specification. The only exception that I think is
covered is the java.* package because an application
class loader needs to do some unusual things to be able
to actually define a class using the java.* package (and
I'm not sure it is even possible on modern Java versions).
Tom
----- Original message -----
From: "David Blevins" <dblevins@xxxxxxxxxxxxx
<mailto:dblevins@xxxxxxxxxxxxx>>
Sent by: "jakartaee-platform-dev"
<jakartaee-platform-dev-bounces@xxxxxxxxxxx
<mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx>>
To: "jakartaee-platform developer discussions"
<jakartaee-platform-dev@xxxxxxxxxxx
<mailto: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: Thu, Jan 6, 2022 11:05 AM
There is an edict that no one should put code under
the java and javax packages unless it has been
approved by the JCP process. I don’t think that is
stated in the resulting specifications, but enforced
separately through trademark.
I’m not sure we have a clear rule of our own for
jakarta.* (we might), but it would make sense and is
likely something we should explicitly document.
Possibly in our JESP.
I know we have a doc that says the package must be
jakarta.*. I don’t recall if it specifically calls
out it is forbidden to use it unless going through
the JESP process.
-David
On Thu, Jan 6, 2022 at 6:34 AM Thomas Watson
<tjwatson@xxxxxxxxxx <mailto:tjwatson@xxxxxxxxxx>>
wrote:
I understand the implementation concern and we
certainly should use that to influence our
decision if it makes life easier for current
implementations. After all, the actual tck
package name we chose is not that important in
the end. Just need to pick a consistent one,
which we own, in my opinion.
But I still am not convinced about it being
clear in any of the Jakarta specifications that
implementations must ignore annotation scanning
of any classes in the javax or jakarta packages,
let alone the class loading rules around such
packages when they are included in an
application. You say "once again it is written
in the spec(s)", but I say it is written very
poorly if the intent is to allow such
optimizations. As an example, I would at least
expect a mention about the jakarta/javax
packages in the CDI specification in the
following sections:
https://jakarta.ee/specifications/cdi/3.0/jakarta-cdi-spec-3.0.html#type_bean_discovery
<https://urldefense.com/v3/__https://jakarta.ee/specifications/cdi/3.0/jakarta-cdi-spec-3.0.html*type_bean_discovery__;Iw!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI1UvYfmM$>
https://jakarta.ee/specifications/cdi/3.0/jakarta-cdi-spec-3.0.html#what_classes_are_beans
<https://urldefense.com/v3/__https://jakarta.ee/specifications/cdi/3.0/jakarta-cdi-spec-3.0.html*what_classes_are_beans__;Iw!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaIf95XO7c$>
All this is not to say I think we must chose
jakarta.tck as the package name. For the sake
of current implementations is sounds like we
shouldn't. But I also think it is a slippery
slope to continually make such decisions on
something that is so unclearly specified. In
the end we can make our decision to not use
jakarta.tck because it helps our existing
implementations. Not because it is written in
the specification as some restriction. If we
want to base our decision on the actual
specification then I think the specification
really needs some work to make it more clear.
Tom
----- Original message -----
From: "Emily Jiang via
jakartaee-platform-dev"
<jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
Sent by: "jakartaee-platform-dev"
<jakartaee-platform-dev-bounces@xxxxxxxxxxx
<mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx>>
To: "jakartaee-platform developer
discussions"
<jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
Cc: "Emily Jiang" <emijiang6@xxxxxxxxxxxxxx
<mailto:emijiang6@xxxxxxxxxxxxxx>>
Subject: [EXTERNAL] Re:
[jakartaee-platform-dev] Standardizing new
TCK packages (was: package prefixes for
Jakarta Batch TCK-related classes?
org.eclipse.ee4j.batch ?)
Date: Thu, Jan 6, 2022 4:17 AM
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
<mailto: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
<https://urldefense.com/v3/__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__;Iw!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI5VtoHCI$>
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
<https://urldefense.com/v3/__http://jakarta.ee/__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaIpTgzh4A$>
domain and can potentially use either of
these:
- ee.jakarta.*
- ee.jakarta.tck.*
I also just looked and jakartatck.org
<https://urldefense.com/v3/__http://jakartatck.org/__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI9XnaEXY$>
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
<https://urldefense.com/v3/__http://jakartatck.org/__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI9XnaEXY$>
to the Working Group like I did when
purchased jakarta.ee
<https://urldefense.com/v3/__http://jakarta.ee/__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaIpTgzh4A$>.
--
David Blevins
http://twitter.com/dblevins
<https://urldefense.com/v3/__http://twitter.com/dblevins__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaISZK9wMo$>
http://www.tomitribe.com
<https://urldefense.com/v3/__http://www.tomitribe.com/__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaIgJIEvq8$>
> On Jan 5, 2022, at 1:19 PM, Thomas
Watson <tjwatson@xxxxxxxxxx
<mailto: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
<mailto:rmannibucau@xxxxxxxxx>>
> Sent by: "jakartaee-platform-dev"
<jakartaee-platform-dev-bounces@xxxxxxxxxxx
<mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx>>
> To: "jakartaee-platform developer
discussions"
<jakartaee-platform-dev@xxxxxxxxxxx
<mailto: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
<mailto: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
<https://urldefense.com/v3/__https://jakarta.ee/specifications/servlet/5.0/jakarta-servlet-spec-5.0.html*web-application-class-loader__;Iw!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI5PYO9CI$>
>
> 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
<mailto:rmannibucau@xxxxxxxxx>>
> Sent by: "jakartaee-platform-dev"
<jakartaee-platform-dev-bounces@xxxxxxxxxxx
<mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx>>
> To: "Emily Jiang"
<emijiang6@xxxxxxxxxxxxxx
<mailto:emijiang6@xxxxxxxxxxxxxx>>
> Cc: "jakartaee-platform developer
discussions"
<jakartaee-platform-dev@xxxxxxxxxxx
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto:jlmonteiro@xxxxxxxxxxxxx>> a écrit :
> Sounds like a good improvement to me
as well
>
> Le mar. 4 janv. 2022 à 22:00, David
Blevins <dblevins@xxxxxxxxxxxxx
<mailto:dblevins@xxxxxxxxxxxxx>> a écrit :
> > On Jan 4, 2022, at 12:23 PM, Emily
Jiang via jakartaee-platform-dev
<jakartaee-platform-dev@xxxxxxxxxxx
<mailto: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
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI8cIoI9k$>
>
_______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI8cIoI9k$>
>
_______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI8cIoI9k$>
>
>
> --
> Thanks
> Emily
>
>
_______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI8cIoI9k$>
>
>
> --
> Thanks
> Emily
>
>
>
> --
> Thanks
> Emily
>
>
_______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI8cIoI9k$>
>
>
>
>
_______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI8cIoI9k$>
>
_______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI8cIoI9k$>
>
>
>
>
_______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI8cIoI9k$>
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI8cIoI9k$>
--
Thanks
Emily
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI8cIoI9k$>
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI8cIoI9k$>
--
Sent from Gmail Mobile
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI8cIoI9k$>
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI8cIoI9k$>
