Open svanteschubert opened 4 years ago
At least for my simple use case, adding the following src/main/java/module-info.java
seemed to work:
module org.odftoolkit.odfdom {
requires java.desktop;
requires java.logging;
requires java.xml;
requires java.rdfa;
requires xercesImpl;
requires org.json;
requires org.slf4j;
requires org.apache.jena.core;
requires org.apache.commons.compress;
requires org.apache.commons.lang3;
requires commons.validator;
requires serializer;
exports org.odftoolkit.odfdom;
// and other exported packages
}
I had to disable the tests java/org/odftoolkit/odfdom/pkg/GRDDLTest.java
and java/org/odftoolkit/odfdom/pkg/RDFMetadataTest.java
since I couldn't figure out how to make the jena-core:tests visible (related: https://github.com/eclipse/jetty.project/issues/3080). While this is nice to have, it still won't work properly until [xercesImpl-2.12.0.jar, serializer-2.7.2.jar, java-rdfa-1.0.0-BETA1.jar, commons-validator-1.6.jar] have also migrated.
Hello Miasma,
Thank you for your contribution and insights. So all our dependent project JARS you mentioned need to be transitioned to JDK 9 prior as well.
Any further information & help is most welcome.
Best regards, Svante
Damian answered the current RDFa GitHub repository, which is also creating the recent Maven artefact is: https://github.com/iteggmbh/java-rdfa
I am new to Java 9 modularity, but I thought the following workaround could be of interest to others:
If your project depends on odftoolkit and your IDE reports compilation errors due to Java modularity, you might want to exclude the xml-apis
dependency from odftoolkit, which duplicates native libraries already provided by another module, as follows (for Maven):
<dependency>
<groupId>org.odftoolkit</groupId>
<artifactId>odfdom-java</artifactId>
<version>0.9.0-RC1</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
Is anyone able to provide a pull request that enables Java 9 modularity? Or at least provide a pull request where we can iterate upon and list the remaining problems?
I would like to understand what is the need you are looking into fulfilling here. I think Java 9 modularity can be "enabled" by adding some basic module metadata in module-info.java
as mentioned by @miasma, but I do not know if such a setup would actually solve the issue you have in mind?
In other words, I would like to understand in which scenarios it is important to users that this Java 9 modularity is used.
@wetneb Personally, I have no special use case in mind. I am happy to solve it with a patch based on the draft in the beginning. :-) When I did a quick test in VSCode to add the initially mentioned src/main/java/module-info.java I got a lot of errors, that some of the above mentioned would be not modules. That lead to my previous request for feedback/help.
Someone who is already using Java 9 modularity might assist us in adding this concept to the ODF Toolkit JARs.
See also: https://www.oracle.com/corporate/features/understanding-java-9-modules.html https://www.baeldung.com/java-9-modularity