| Re: [jakartaee-platform-dev] [External] : Re: Standardizing new TCK packages (was:package prefixes for Jakarta Batch TCK-related classes?org.eclipse.ee4j.batch ?) |
On 1/10/22 5:54 PM, Thomas Watson wrote:
> +1
> So far we have only agreed that for Jakarta 10 the jakarta.* package
> name must NOT be used. Ideally we would have a vote so that any new
> TCKs for Jakarta 10 would be able to use an agreed package name, but I
> don't think we should delay anything for Jakarta 10 outside of not allow
> jakarta.* be used for TCK packages.
just to make sure I understand this - in jsonp-tck which has been
extracted from the platform repo to jsonp repo, tests were moved to
`jakarta.jsonp.tck` package and the TCK as such is considered almost
complete. We have one pending PR there + final review pending before
turning the draft spec PR into the regular one. Are we really required
to refactor everything at this stage again?
--lukas
>
> Tom
>
> ----- Original message -----
> From: "Emily Jiang via jakartaee-platform-dev"
> <jakartaee-platform-dev@xxxxxxxxxxx>
> Sent by: "jakartaee-platform-dev"
> <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
> To: "jakartaee-platform developer discussions"
> <jakartaee-platform-dev@xxxxxxxxxxx>
> Cc: "Emily Jiang" <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: Mon, Jan 10, 2022 10:22 AM
> Hi Scott,
> My responses are inline below.
>
> Thanks
>
> Emily
>
> On Mon, Jan 10, 2022 at 4:14 PM Scott Marlow <smarlow@xxxxxxxxxx
> <mailto:smarlow@xxxxxxxxxx>> wrote:
>
> On 1/6/22 4:51 PM, David Blevins wrote:
>> It sounds like we're all coming to agreement and we're down to
>> just picking the name. To Nathan's point, being quick is key.
>>
>> Here's a proposal on how to wrap this up:
>>
>> - We give till Monday 8am Pacific for people to suggest a
>> package prefix that does not start with "jakarta"
>>
>> - On Monday we start a 72-hour rank choice vote here on the
>> mailing list.
>>
>> - If the chosen option needs to be eliminated for any reason,
>> we go to the second choice, etc. No new vote necessary (yay,
>> ranked choice).
>>
>> - The chosen prefix would be a recommendation for Jakarta EE
>> 10 and a requirement for Jakarta EE 11. TCK classes from
>> Jakarta EE 9.x and before are exempt, though we may chose to
>> have a separate discussion to change them at some point.
>
> Will the vote be for recommending that new TCK tests to be added
> to EE 10 will use the package prefix?
>
> I think if possible, use the agreed package prefix. If not, leave
> it for now. I think the minimum is not to use jakarta.* prefix as it
> might cause issues.
>
> Will the vote be for requiring that new TCK tests to be added to
> EE 11 will use the package prefix?
>
> Jakarta EE 11 new TCKs must use the new namespace.
>
> Scott
>
>> Unless there are other proposals, I'll kick that vote off on
>> Monday.
>>
>>
>> -David
>>
>>> On Jan 6, 2022, at 10:51 AM, Nathan Rauh
>>> <nathan.rauh@xxxxxxxxxx> <mailto:nathan.rauh@xxxxxxxxxx> wrote:
>>>
>>> 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>
>>> <mailto:rmannibucau@xxxxxxxxx>
>>> To: "jakartaee-platform developer discussions"
>>> <jakartaee-platform-dev@xxxxxxxxxxx>
>>> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
>>> Date: 01/06/2022 12:18 PM
>>> 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>
>>> <mailto: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 | Book
>>>
>>>
>>> Le jeu. 6 janv. 2022 à 18:50, Emily Jiang via
>>> jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
>>> <mailto: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.
>>>
>>> Thanks
>>> Emily
>>>
>>> On Thu, Jan 6, 2022 at 3:41 PM Nathan Rauh
>>> <nathan.rauh@xxxxxxxxxx> <mailto: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>
>>> <mailto:werner.keil@xxxxxxx>
>>> To: "jakartaee-platform developer discussions"
>>> <jakartaee-platform-dev@xxxxxxxxxxx>
>>> <mailto: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>
>>> <mailto: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
>>> <mailto: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 <mailto: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>
>>> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
>>> To: "jakartaee-platform developer discussions"
>>> <jakartaee-platform-dev@xxxxxxxxxxx>
>>> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
>>> Cc: "Emily Jiang" <emijiang6@xxxxxxxxxxxxxx>
>>> <mailto: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>
>>> <mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx>
>>> <Mail Attachment.png>
>>>
>>>
>>>
>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUwSZ-fdQ$>
>>>
>>> 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
>>> <https://urldefense.com/v3/__http://jakarta.ee__;!!ACWV5N9M2RV99hQ!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUW4WLeak$>.
>>>
>>>
>>> --
>>> David Blevins
>>> http://twitter.com/dblevins
>>> <https://urldefense.com/v3/__http://twitter.com/dblevins__;!!ACWV5N9M2RV99hQ!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUCsNz8Ac$>
>>> http://www.tomitribe.com
>>> <https://urldefense.com/v3/__http://www.tomitribe.com__;!!ACWV5N9M2RV99hQ!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUFDHi1o4$>
>>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNU5GWZKBU$>
>>>>
>>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>>>> _______________________________________________
>>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>>>> _______________________________________________
>>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>>>>
>>>>
>>>> --
>>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>>>>
>>>>
>>>> --
>>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>>>> _______________________________________________
>>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>>> _______________________________________________
>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>>>
>>>
>>> --
>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>>> --
>>> Mike Milinkovich
>>> Executive Director | Eclipse Foundation AISBL
>>> Twitter:@mmilinkov
>>>
>>> <Mail Attachment.png>
>>> This email has been checked for viruses by Avast antivirus
>>> software.
>>> www.avast.com
>>> <https://urldefense.com/v3/__http://www.avast.com__;!!ACWV5N9M2RV99hQ!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUCXt-WYc$>
>>> [attachment "graycol.gif" deleted by Nathan
>>> Rauh/Rochester/IBM]
>>> _______________________________________________
>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>>>
>>>
>>> _______________________________________________
>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>>>
>>>
>>>
>>> --
>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNU8nXomjs$>
>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>>>
>>>
>>> _______________________________________________
>>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>> _______________________________________________
>> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
> _______________________________________________
> 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!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>
>
>
> --
> 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
> <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$>
>
>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!cn8X0yvU3tEbaXf3WeZi58uAGoWiyL4tLW1L6wI-c6XOiGzzbP2ZquzEDJNUcvjUzd0$
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev