Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] targeting JDK 8 *and* JDK 11?

Lukas,

While Carlos tried to provide some input from the MicroProfile toolchains, Mike Milinkovich also just confirmed in a different thread, that compatibility needs for Jakarta EE and MicroProfile are often quite different, so it could be fine for MicroProfile 3 or 4 to drop Java 8 or 9 support and require Java 11 or 12 as the minimum version, Jakarta EE has to support Java 8 at least until Jakarta EE 9 as a minimum version I am pretty sure.

It would also be beneficial for individual Jakarta EE specs and their teams if one or two working solutions were available that could act as a blueprint for "Jigsaw" modularity and where that became relevant also multi-release-jars.

Werner





On Mon, Sep 23, 2019 at 3:13 PM Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:
If dropping support for JDK 8 is the goal of your project, then I'd
consider replacing source/target properties with
'maven.compiler.release' property. Switching over to
maven-compiler-plugin:3.8.1 to enjoy benefits of
https://issues.apache.org/jira/browse/MCOMPILER-322 may be another thing
you want to consider.

...but back to the point - the problem is not in getting 'mvn clean
install javadoc:jar' or alternatives to work on JDK 11 properly. Problem
is to make just 'mvn javadoc:javadoc' or 'mvn javadoc:jar' working.

thanks,
--lukas

On 9/23/19 2:46 PM, Werner Keil wrote:
> Carlos,
>
> You replaced Java 8 with 11 in your MP tool chain, I cannot see any
> double execution of Maven Compiler, so you may have fixed the Javadoc
> issue at the cost of no longer working with Java 8.
>
> The Moneta RI builds against Java 9 to 11 without problems, but we also
> use the dual compile option of Maven Compiler and both API and RI work
> with Java 8 demos.
>
> Werner
>
> carlos andres de la rosa <kusanagi12002@xxxxxxxxx
> <mailto:kusanagi12002@xxxxxxxxx>> schrieb am Mo., 23. Sep. 2019, 14:04:
>
>     Hello folks
>
>     I already pass for this javadoc plugin issue with java 11 on mp
>     fault tolerance spec if you wanna check below is a pull request that
>     is compiling with java 11
>     https://github.com/eclipse/microprofile-fault-tolerance/pull/443
>
>     I hope that maybe can help you
>
>     Thank you
>
>     Best
>
>
>     On Mon, Sep 23, 2019 at 1:28 PM Lukas Jungmann
>     <lukas.jungmann@xxxxxxxxxx <mailto:lukas.jungmann@xxxxxxxxxx>> wrote:
>
>         On 9/21/19 1:13 AM, Bill Shannon wrote:
>          > Thanks for the pointers, Lukas.  The jaxb-api approach seems
>         to work
>          > pretty well.
>
>         the drawback of this particular solution is that the correctness of
>         module descriptor is not being checked at compile time by javac
>         - ie if
>         ServiceLoader is used by the code being compiled, javac can detect
>         missing 'use' declaration in module-info and fail eventually; in
>         the
>         setup used by jaxb-api, module-info is compiled against class
>         files, so
>         no such check is being done.
>
>         This as such may or may not be a problem depending on the
>         complexity of
>         the project in question and personal knowledge of its internals.
>
>          >
>          > However, javadoc isn't working:
>          >
>          > [ERROR] Failed to execute goal
>          > org.apache.maven.plugins:maven-javadoc-plugin:3.1.1:javadoc
>         (default) on project
>          > jakarta.activation: An error has occurred in Javadoc report
>         generation:
>          > [ERROR] javadoc: error - No source files for package
>         javax.activation
>          >
>          > I even tried "mvn javadoc:javadoc" on the jaxb-api project
>         and it fails
>          > for a different reason:
>
>         blame buggy maven-javadoc-plugin here[1]; what must work for me
>         is 'mvn
>         clean install' and 'mvn clean install -Poss-release' (with
>         -Dgpg.skip=true eventually). I treat 'javadoc:javadoc' as nice
>         to have
>         thing, so unless there is a strong wish and demand for that, it is
>         unlikely that I'll be putting in some solution for it (read as
>         "IMHO too
>         much work for a little gain")
>
>          >
>          > [ERROR] Failed to execute goal
>          > org.apache.maven.plugins:maven-javadoc-plugin:3.1.1:javadoc
>         (default-cli) on
>          > project jakarta.xml.bind-api: An error has occurred in
>         Javadoc report generation:
>          > [ERROR] Exit code: 1 - error: module not found: java.xml.bind
>          >
>          > I played around with the javadoc tool by hand, using the
>         options the
>          > maven-javadoc-plugin generates, and I can't figure out how to
>         generate
>          > the javadocs for a module.  Have you made this work?
>
>         yes, I made that work - removing lines related to
>         '--patch-module' and
>         '--module-source-path' options and explicitly adding
>         '--source-path'
>         pointing to the main source roots (src/main/java etc) helped
>
>         thanks,
>         --lukas
>
>         [1]: https://issues.apache.org/jira/browse/MJAVADOC-622
>
>          >
>          >
>          > Bill Shannon wrote on 9/19/19 11:01 AM:
>          >> Lukas Jungmann wrote on 9/19/19 5:12 AM:
>          >>> Hi Bill,
>          >>>
>          >>> On 9/19/19 2:29 AM, Bill Shannon wrote:
>          >>>> What's the state of the art for building a jar file that
>         contains class
>          >>>> files that will work on JDK 8, and a module-info.class
>         that will work
>          >>>> on JDK 11?
>          >>>
>          >>> Are you looking just for this or also for ability to have
>         multi-release jars?
>          >>
>          >> I don't need a multi-release jar file.
>          >>
>          >>> Are you looking for slightly more advanced things like
>         module-info being altered
>          >>> by the build as needed - ie because you have a main-class
>         in one of the projects
>          >>> (maven-jar-plugin:3.1.2+ is required), or you want to
>         include project version in
>          >>> module info (maven-compiler-plugin:3.8.1+ is required) etc?
>          >>
>          >> I don't think I need that.
>          >>
>          >>> All JAXB/JAXWS related projects are somehow dealing with
>         this as all of them are
>          >>> java modules for some time already and some of them are
>         also multi-release jars;
>          >>> jsonp/yasson are another projects to look at eventually -
>         should I pick up some
>          >>> examples, jaxb-api can be one of them - it is small project
>         with module-info, a
>          >>> multi-release jar and compiles everything exactly ones[1],
>         a project which is
>          >>> not MR jar but contains "old" tests which are now being run
>         within JPMS can be
>          >>> metro-policy[2] (its double-compilation is going to be
>         fixed in the (near)
>          >>> future). Old JAXB/SAAJ/JAXWS 'RI's are another examples
>         should you be looking
>          >>> for bigger projects - note that I'm updating them these
>         days to adopt recent
>          >>> changes in maven plugins, so what is there today, may be
>         different tomorrow (or
>          >>> day after :-))...
>          >>>
>          >>>   Based on my experience, if you get on this path, my
>         recommendation is to use
>          >>> Maven 3.6.0. 3.6.1 is safe if you don't need to use Eclipse
>         Tycho, with 3.6.2,
>          >>> the copyright plugin does not work[3]. If there is a need
>         for Ant, make sure
>          >>> 1.10.6+ is used because older versions do not work
>         correctly out-of-the-box if
>          >>> the build uses a task from a library which is a
>         multi-release jar[4].
>          >>>   As for what maven build plugins to use - general advice
>         is to always use the
>          >>> latest versions.
>          >>
>          >> Thanks for the pointers, I'll look at those projects.
>          >>
>          >>> thanks,
>          >>> --luksa
>          >>>
>          >>> [1]:
>         https://github.com/eclipse-ee4j/jaxb-api/blob/master/jaxb-api/pom.xml
>          >>> [2]:
>         https://github.com/eclipse-ee4j/metro-policy/blob/master/policy/pom.xml
>          >>> [3]:
>         https://github.com/eclipse-ee4j/glassfish-copyright-plugin/issues/7
>          >>> [4]: https://bz.apache.org/bugzilla/show_bug.cgi?id=62952
>          >>>
>          >>>    The last time I looked at this all I found were kludges
>          >>>> that resulted in compiling everything twice, or very
>         complex Maven
>          >>>> configurations that depended on using multiple versions of
>         the JDK
>          >>>> to compile.  Is there a better way?  Is there an existing
>         project
>          >>>> that would be a good example?
>          >>>> _______________________________________________
>          >>>> jakarta.ee-community mailing list
>          >>>> jakarta.ee-community@xxxxxxxxxxx
>         <mailto:jakarta.ee-community@xxxxxxxxxxx>
>          >>>> To change your delivery options, retrieve your password,
>         or unsubscribe from
>          >>>> this list, visit
>          >>>> https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>          >>>>
>          >>> _______________________________________________
>          >>> jakarta.ee-community mailing list
>          >>> jakarta.ee-community@xxxxxxxxxxx
>         <mailto:jakarta.ee-community@xxxxxxxxxxx>
>          >>> To change your delivery options, retrieve your password, or
>         unsubscribe from
>          >>> this list, visit
>          >>> https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>          >> _______________________________________________
>          >> jakarta.ee-community mailing list
>          >> jakarta.ee-community@xxxxxxxxxxx
>         <mailto:jakarta.ee-community@xxxxxxxxxxx>
>          >> To change your delivery options, retrieve your password, or
>         unsubscribe from this list, visit
>          >> https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>          >>
>         _______________________________________________
>         jakarta.ee-community mailing list
>         jakarta.ee-community@xxxxxxxxxxx
>         <mailto:jakarta.ee-community@xxxxxxxxxxx>
>         To change your delivery options, retrieve your password, or
>         unsubscribe from this list, visit
>         https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>
>
>
>     --
>
>     *Carlos Andres De La Rosa | Software Architect*
>
>     Mobile: + <tel:%2B57-3163226522>32465445631
>
>     Skype: carlosa.dlr
>
>     _______________________________________________
>     jakarta.ee-community mailing list
>     jakarta.ee-community@xxxxxxxxxxx
>     <mailto:jakarta.ee-community@xxxxxxxxxxx>
>     To change your delivery options, retrieve your password, or
>     unsubscribe from this list, visit
>     https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>
>
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

Back to the top