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? 
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
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