Bill,
It seems you don't need a multi-release-jar at this point, so please also check out the Jakarta JSON projects or ask Dmitry about it.
They don't use Ant or AntRun either, that only is one of the few working options, if you need Multi-release in Maven, to add a module-Info and still be backward compatible with Java 8, you don't need that. Maven toolchain is enough for that.
We also used a similar approach in JSR 354 which needs no multi-release JAR, but declared a module-info similar to JSON-P or JSON-B.
Werner
Thanks for the pointers, Lukas. The jaxb-api approach seems to work
pretty well.
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:
[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?
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
>
_______________________________________________
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
