Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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$

Back to the top