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/6/22 11:05 PM, Thomas Watson wrote:
+1

Tom

    ----- Original message -----
    From: "David Blevins" <dblevins@xxxxxxxxxxxxx>
    Sent by: "jakartaee-platform-dev"
    <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
    To: "jakartaee-platform developer discussions"
    <jakartaee-platform-dev@xxxxxxxxxxx>
    Cc:
    Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Standardizing new
    TCK packages (was: package prefixes for Jakarta Batch TCK-related
    classes? org.eclipse.ee4j.batch ?)
    Date: Thu, Jan 6, 2022 3:58 PM
[snip/]
    "The packages java, javax, and jakarta are reserved and trademarked.
      Applications should not create or modify classes under these
    packages.  Applications that do so have unspecified behavior and may
    not deploy, function properly at runtime, or be portable."

Let's say I have an app for Tomcat which uses persistence API. Based on this, can or can not the persistence API which I need, be packaged within the war? If I have it included in the war, doesn't it fall under "unspecified behavior"?

thanks,
--lukas


    -David
    On Jan 6, 2022, at 1:43 PM, Thomas Watson <tjwatson@xxxxxxxxxx
    <mailto:tjwatson@xxxxxxxxxx>> wrote:
    One slight tweak.  The last sentence should use "may" instead of
    "will" and needs a comma before "or be portable":

    "The packages java, javax, and jakarta are reserved and
    trademarked.  Applications should not create or modify classes
    under these packages.  Applications that do so may have
    unspecified behavior and may not deploy, function properly at
    runtime, or be portable."

    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 3:34 PM

        I like it.  How about this as a tweak to broaden it a bit?
        "The packages java, javax, and jakarta are reserved and
        trademarked.  Applications should not create or modify classes
        under these packages. Applications that do so will have
        unspecified behavior and may not deploy, function properly at
        runtime or be portable."
-- 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 6, 2022, at 1:29 PM, Thomas Watson
        <tjwatson@xxxxxxxxxx <mailto:tjwatson@xxxxxxxxxx>> wrote:
        I think the statement needs to go one step further and state:
        "Applications that do so will have unspecified behavior when
        attempts are made by the platform to load and process such
        classes."
        But I would like to see this added to at least the Platform
        specification.

        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 2:51 PM

            Agree adding something to the specifications is a good
            idea and very reasonable thing to do.
            We could potentially expand the mandatory boilerplate at
            the start of each specification with something like:
            "The packages java, javax, and jakarta are reserved and
            trademarked.  Applications should not create or modify
            classes under these packages."
            We could have it so that the above could be mandatory for
            all specs going forward.  If spec teams (including the
            platform spec) want to go a few steps beyond that and
            define how the failure should look, etc. hat's also
            reasonable.
            The only trick to actually rejecting applications that
            have java, javax, or jakarta in them is many applications
            include javax libraries in their wars.  In my experience
            most app servers and servlet implementations will
            tolerate/ignore that to different degrees.  With Tomcat
            for example if you have javax.servlet as an API jar in
            your war, it's not going to work.  However, Tomcat will
            tolerate javax.xml.rs
            <https://urldefense.com/v3/__http://javax.xml.rs/__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaIDOLova8$>,
            javax.ejb, javax.persistence, etc as they aren't shipped
            by the server and don't conflict.  In early versions of
            TomEE including those would result in failures at
            runtime.  Later we modified the classloader so those
            would simply be ignored as it became clear other servers
            were doing the same and facing issues porting to us.
            That statement really proves your point.
            What do you think about having a standard "don't do that"
            statement at the top of each spec as mandatory with an
            option for spec teams to go further as they have time/energy?
            Would something like that go far enough?

-- 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 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$>
            _______________________________________________
            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
    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
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!Z8ja-nacf6m_tXUozU1HpHEeb_oUldxQnW0azQwh1M7d4G_YvAv8l7qDZiaI8cIoI9k$



Back to the top