Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [External] : Re: : Re: The location of module-info.java and muti release jar 
On 10/8/21 6:33 PM, Scott Stark wrote:
The dependency injection-api and bean-validation are also widely used outside of Jakarta containers and would want to keep SE 8 support. So it seems like we want to have api jars not making feature changes compiled with source/target of 8 with a root module-info.class compiled with source/target of 9 rather than using a multi-release jar. 

So I see the following from the maven-compiler page:
https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html <https://urldefense.com/v3/__https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html__;!!ACWV5N9M2RV99hQ!aQd3WGbeAEgIQGVM-KOz6QwuKbKdxa_sYq7-T41MCncoA7fZkHaWtXUbjmgSx8j8lko$>
Which has two explicit executions specified. I tried out the JAF api build which is producing the same output, but it only has one execution explicitly stated: https://github.com/eclipse-ee4j/jaf/blob/master/api/pom.xml <https://urldefense.com/v3/__https://github.com/eclipse-ee4j/jaf/blob/master/api/pom.xml__;!!ACWV5N9M2RV99hQ!aQd3WGbeAEgIQGVM-KOz6QwuKbKdxa_sYq7-T41MCncoA7fZkHaWtXUbjmgSv84QNHM$>
Running in verbose mode I do see two executions of the compiler running, just not sure how that is happening.
that's maven, the convention over configuration.... Short answer would be that the execution with id `default-compile` runs even if undefined. https://maven.apache.org/guides/mini/guide-default-execution-ids.html gives more details.
To see the full pom with applied interpolation, inheritance and active profiles maven will run and not its shortened version written by human beings, use `mvn help:effective-pom` 

thanks,
--lukas
On Oct 8, 2021 at 9:56:56 AM, BJ Hargrave <hargrave@xxxxxxxxxx <mailto:hargrave@xxxxxxxxxx>> wrote: 

    Remember that some API jars are used by more the the Jakarta EE
    platform implementations. And in those scenarios, you should be
    careful about forcing consumers to update to Java 11 when the can't
    or don't want to.
    Using JUnit 5 as an example, they have a broad user community which
    includes those still targeting Java 8 runtimes and need to test there.
    JSON Processing and RESTful Web Services may be somethings that are
    useful outside of the platform in a variety of scenarios and care
    must be taken with a decision to force consumers to Java 11. So
    while it places a build engineering burden on us to build mixed
    target jars, we can support a broad user community this way.
    --

    BJ Hargrave
    Senior Technical Staff Member, IBM // office: +1 386 848 1781
    OSGi Fellow and OSGi Specification Project lead // mobile: +1 386
    848 3788
    hargrave@xxxxxxxxxx <mailto:hargrave@xxxxxxxxxx>

        ----- Original message -----
        From: "Thomas Watson" <tjwatson@xxxxxxxxxx
        <mailto:tjwatson@xxxxxxxxxx>>
        Sent by: "jakartaee-platform-dev"
        <jakartaee-platform-dev-bounces@xxxxxxxxxxx
        <mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx>>
        To: jakartaee-platform-dev@xxxxxxxxxxx
        <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
        Cc:
        Subject: [EXTERNAL] Re: [jakartaee-platform-dev] : Re: The
        location of module-info.java and muti release jar
        Date: Fri, Oct 8, 2021 08:53
        For Jakarta 10 it would be a bit more simple to move on to Java
        11 and stop providing Java 8 targeted classes
        (+module-info.class).  How important (or large) is the group of
        developers that want the latest and greatest Jakarta spec
        version but are unwilling to move to a more modern Java version?
        I've used the double compile approach to generate a proper
        module-info.class for a Java 8 project.  As you say, this does
        help generate and validate a proper module-info.class, but I've
        found that doesn't always play nicely when in an IDE.

        Tom

            ----- Original message -----
            From: "Lukas Jungmann" <lukas.jungmann@xxxxxxxxxx
            <mailto:lukas.jungmann@xxxxxxxxxx>>
            Sent by: "jakartaee-platform-dev"
            <jakartaee-platform-dev-bounces@xxxxxxxxxxx
            <mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx>>
            To: jakartaee-platform-dev@xxxxxxxxxxx
            <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
            Cc:
            Subject: Re: [jakartaee-platform-dev] [External] : Re: The
            location of module-info.java and muti release jar
            Date: Thu, Oct 7, 2021 8:17 PM
            On 10/7/21 9:39 PM, BJ Hargrave wrote:
             > Some APIs may not want to step up to target Java 11 and
            will want to
             > remain with target Java 8 for their API class files. In
            this case, they
             > will need to compile module-info.java with target 11 and
            add that class
             > file into the root of the jar. So there will be 2 compile
            steps in the
             > build (one for module-info, and the other for the other
            classes).

            My experience says having 2 complete compilations - first
            for everything
            by 11, second everything minus module-info by 8 - is more
            reliable.

            There were 2 sets of issues I faced when I was not following
            this:
            1) java.lang.VerifyError (see
            https://github.com/eclipse-ee4j/mail/issues/489
            <https://urldefense.com/v3/__https://github.com/eclipse-ee4j/mail/issues/489__;!!ACWV5N9M2RV99hQ!aQd3WGbeAEgIQGVM-KOz6QwuKbKdxa_sYq7-T41MCncoA7fZkHaWtXUbjmgSoddayC8$> )
            2) when module-info is compiled against pre-compiled
            classes, javac
            won't issue warnings/errors for mistakes like missing "uses" and
            probably others

            ...just saying...

            thanks,
            --lukas


             > This is common practice in many projects. For example,
            see JUnit 5. All
             > their jars have class files targeting Java 8 and also
            include a (target
             > 11) module-info.class file in the root of the jar.
             > A Java 8 runtime will not care about a module-info.class
            file in the jar
             > and so will not attempt to load it. A Java 11 runtime
            will be able to
             > load the module-info.class and the other target 8 class
            files just fine.
             > That is, there is no need for the complexity of
            Multi-Release jars just
             > to include a module-info.class file in a jar with other
            target 8 class
             > files.
             > --
             >
             > BJ Hargrave
             > Senior Technical Staff Member, IBM // office: +1 386 848 1781
             > OSGi Fellow and OSGi Specification Project lead //
            mobile: +1 386 848 3788
             > hargrave@xxxxxxxxxx <mailto:hargrave@xxxxxxxxxx>
             >


_______________________________________________
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!aQd3WGbeAEgIQGVM-KOz6QwuKbKdxa_sYq7-T41MCncoA7fZkHaWtXUbjmgSj1exd_Y$

Back to the top