| Re: [jakarta.ee-community] targeting JDK 8 *and* JDK 11? |
Werner
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