Related
I have a Java 11 project embedding Tomcat:
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-core</artifactId>
<version>10.1.0</version>
</dependency>
The Tomcat-specific code is in a subproject with only two classes. When I compile using Maven 3.8.6 and Java 17 using -Xlint:all, I see the following warning for that subproject:
[WARNING] Cannot find annotation method 'value()' in type 'aQute.bnd.annotation.spi.ServiceConsumer': class file for aQute.bnd.annotation.spi.ServiceConsumer not found
Doing a bit of searching brings up similar (but not exact) things, such as Lombok Issue #2145, which hints that I may need to add some sort of extra dependency such as biz.aQute.bnd:bndlib or org.osgi:osgi.annotation. But even after adding those dependencies, the warning remains.
Where is this error coming from, and what does it mean? I don't have any #ServiceConsumer annotation in my source code, and I couldn't find any in the Tomcat classes I'm extending, either. How can I make it go away?
I filed Tomcat Bug 66299.
I discussed this on the Tomcat users mailing list users#tomcat.apache.org (thanks Mark), and here's what is happening:
Tomcat effectively has two builds:
What I call the Tomcat "primary build" uses Ant with build.xml, which compiles the source files, creates all the JARs and binaries, and publishes them to Maven Central (Nexus).
Any "secondary build" by third parties using the published JARs and POMs, using e.g. org.apache.tomcat.embed:tomcat-embed-core:10.1.0 with Maven.
The latest versions of direct dependencies are found in the Tomcat repository inside build.properties.default.
The primary build generates JPMS and OSGi metadata, so some classes are annotated with the bnd annotation aQute.bnd.annotation.spi.ServiceConsumer. Currently Tomcat gets this annotation from biz.aQute.bnd:biz.aQute.bnd:6.3.1, which is apparently some aggregate JAR; the same annotation can be found in the smaller biz.aQute.bnd:biz.aQute.bnd.annotation:6.3.1.
The aQute.bnd.annotation.spi.ServiceConsumer annotation source code uses the OSGi annotation org.osgi.annotation.bundle.Requirement. Currently this annotation can be found in org.osgi:osgi.annotation:8.1.0.
The bnd and OSGi annotations remain part of the compiled classes even though they are not used at runtime and are not technically needed in any secondary builds.
If you want to inform Maven and javac where these classes are so that they will not appear missing (if you are compiling with some variations of -Xlint), but that they nevertheless will not be needed at runtime (and technically aren't even needed at compile time in a secondary build) and should not be distributed in the resulting JAR, you can note them in your pom.xml file using the provided scope.
<dependency>
<groupId>biz.aQute.bnd</groupId>
<artifactId>biz.aQute.bnd.annotation</artifactId>
<version>6.3.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>osgi.annotation</artifactId>
<version>8.1.0</version>
<scope>provided</scope>
</dependency>
Maven will download these artifacts during your build thereby removing the warning, but they will not be included in the resulting artifacts of your build.
When referencing simple .jar files, Eclipse shows an error stating:
The package java.awt is accessible from more than one module: <unnamed>, java.desktop
This happens for instance when javax.awt or javax.swing is included in the .jar files.
The simplest example would be the following:
package test;
import javax.swing.JDialog;
public class Test {
public static void main(String[] args) {
new JDialog();
}
}
Adding a .jar file to the classpath with only the folder structure javax/swing (no files needed) will cause the error to appear. I'm using JDK 10/12 (neither works). Setting the compiler compliance to 1.8 makes the whole thing work again.
On another machine with Eclipse 2018-09 this works with compiler compliance set to 10.
I'm on Eclipse 2019-03, on a (for testing purposes) freshly installed Eclipse 2018-09 it works fine. Why?
Edit June/2020 (Solution)
As the answers correctly stated, this is a restriction built into Java ages ago and only recently was forced upon us. I came into contact with it while migrating a big project with dozens of dependencies to Maven. There were libraries from around the year 2000! There were 'meta libraries' which consisted of several libraries packaged together.
So there was no other way than to identify what was still needed (into the trash with the rest!), update libraries which violate the rules or find replacements for them. This took me many, many hours.
In the end it worked out and we've got a nice Maven project to work with.
This is caused by
a JAR on the Classpath that contains the package java.awt that also exists in the system library but the
JRE System Library is on the Modulepath
In the Java Platform Module System (JPMS) it is not allowed to use the same package in more than one module. If the Modulepath and the Classpath is used, everything on the Classpath is handled as the <unnamed> module (in your case the package java.awt exists in the system module java.desktop and also via the JAR on the Classpath in the module <unnamed>).
Since the JRE System Library cannot be moved from the Modulepath to the Classpath (see this answer by Stephan Herrmann for details), you only have the following options:
Set the compiler compliance to 1.8 (as you already mentioned)
Rebuilt the JAR to avoid Java system library package names inside the JAR (if reflection is used, additional code changes may be necessary):
If you have the source code, change the package names (e.g. change the package and subpackae java to java_util and javax to javax_util) and recreate the JAR
If you have only the .class files you have to decompile the .class files first
Since I'll bet lots of people will be running into this problem with modular Java, I'll help and give the real answer.
This error happens when
you have a dependency in your project
that contains code
using packages
that are also in the modules
being referenced by your project
If your project has set the source compatibility to something like Java 12, it will start enforcing the rule, that has been there all along in Java:
"Don't use packages that belong to the JDK in your own code."
Unfortunately, lots of developers and vendors have done that over the years. Can't do that anymore.
If you set your project to Java 12 source compatibility, Eclipse adds the JDK modules which include everything "java.*" and "javax.*" and even "jdk.*", "org.w3c.*". These packages may be in use by your dependencies or their transitive dependencies.
How to fix
You need to:
look at which package its complaining about
and expand the "Projects and External Dependencies" node in the Package Explorer.
Find out which dependency is using that package.
Then you can simply exclude that dependency from your project.
Or you could get the source of that dependency, if available, and rebuild the jar with changed packages. Otherwise you have to remove that dependency and find a replacement for that technology. Pain huh?
If its a transitive dependency you can often just exclude it. Here is an example of that for Gradle based projects.
GradleConfig.xml:
configurations {
all*.exclude group: 'xml-apis'
}
In my case, it was because I included a dependency (Apache Tika) in the POM.xml file.
I had to force the exclusion of the module that contained the classes with errors while imported at that dependency:
<dependency>
<groupId>org.apache.tika</groupId>
<artifactId>tika-parsers</artifactId>
<version>1.24.1</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
It worked for me that way.
I found a simple solution to troubleshoot this in Eclipse. Hit Ctrl + Shift + T in Eclipse to open the Open Type prompt. Then type the name of the package that is causing the issue. For me, it was org.w3c.dom. Now the search results will show all the locations from where this package is being loaded. Remove every JAR from the classpath that comes in the result other than the JDK 11 library.
My project being a legacy one, I had to remove a lot of JARs from the build path. Also, my project does not use Maven. So removing the JARs was a fairly straightforward step. The steps might vary for other build tools like ANT, Maven, Gradle, etc. I have just explained the troubleshooting steps above.
See also: The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml where I answered:
Disappointingly I don't see any compiler flags to show what jar the problem is with
Even -Xlint:module doesn't seem to show up anything useful and eclipse doesn't shed any light on the issue
Instead to find where java.awt comes from I've been using this script:
mvn dependency:copy-dependencies -DincludeScope=test -DoutputDirectory=deps
for i in deps/*.jar; do if unzip -l $i| grep -q java.awt; then echo $i; fi ; done
Strictly you don't have to specify the scope test as that's the default but I've included it as you might want to use compile instead
I think my flavour of the problem might be useful.
I got this error for classes under javax.xml.stream, by old Maven projects that depend on artifacts like xml-apis, stax-api, or geronimo-stax-api.
Technically, the problem is what others have already said: those artifacts expose the javax.xml.* package without any awareness of Java modules (they were invented later), so the package is automatically assigned to the unnamed module, which conflicts with the same package being included in the JDK's most recent versions, where the package has its own module name, and therefore the same package results in two different modules, which is forbidden.
That said, the practical solution is essentially to work with Maven exclusions to remove those dependencies from your project and let it use the JDK version instead (or, of course, remove them as direct dependencies, if that's your case). Use the equivalent if you're working with another build system.
In theory, the more recent flavours of these packages offered by the JDK might be non backward-compatible, in practice, I doubt such JSR specifications changed much over the years and so far, I haven't seen any issue with their replacement.
Since this is ranks quite high on Google I'm going to drop this here in case it's helpful for someone.
I've found some interesting behaviour with Java 11 and the xmlbeans library. The xmlbeans library is a transitive dependency of Apache POI, a very popular library for working with Microsoft Office documents, it is used to handle the internal XML structures of the newer Office formats. I've tested it with Apache POI 3.9 and it works perfectly fine, despite the error shown by Eclipse. So, I guess in Java 11 this rule it's not fully enforced.
For Apache POI version 5.0.0 using Maven, in the pom.xml:
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi</artifactId>
<version>5.0.0</version>
</dependency>
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi-ooxml</artifactId>
<version>5.0.0</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
Fixed: "The package javax.xml.parsers is accessible from more than one module"
I met a similar issue with the eclipse IDE while upgrading JDK from 1.8 to 11, "The package org.w3c.dom is accessible from more than one module: , java.xml". upgrading eclipse from 2019 to 2021 and setting system JDK home to 11 does not solve it. I don't think it's caused by "org.w3c.dom" existing in different jars of the classpath,dut to "Order and Export" should ordered the search sequence.
After several hours of searching and investigating, this issue is fixed by setting the Java Compiler - Compiler compliance level to 1.8(default is 11).
You can do what other people suggest which is to exclude xml-apis which worked fine with me, but if your are using and an old jaxb-api replace them with jakarta.xml.bind-api:
<dependency>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>2.3.3</version>
</dependency>
and of course upgrade your jaxb-impl to match the same api:
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.3.3</version>
</dependency>
Steps below helped me,
Right click Eclipse project > Properties > Java Build Path
In Libraries tab, remove all the external jar files under Modulepath and add them under Classpath (you can just select all the jars and drag them under Classpath)
Click Apply and Close
Hope it help you too.
Wow, this was a tough one!
Some helpful tips (a summary of my journey through this maze):
This started when I migrated from Java 1.8 to 11.0.11
Right out of the gate this caused problems. I needed to change the syntax for how to specify the Java version for the maven build plug in as shown below:
Before
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
After
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<release>11</release>
</configuration>
</plugin>
After that, everything compiled at a command prompt. However, when opening the project in Eclipse, I got a bunch of errors as shown in the next section.
Getting "<class> cannot be resolved to a type" errors
When I got errors in Eclipse and not at the command line I immediately started looking at configuration settings in Eclipse to no avail. After some googling I came to this post. The post at https://www.eclipse.org/forums/index.php/t/1110036/ was also very helpful.
Finding what resources were the problem
The answer to this post by #Anu suggesting using <shift><ctrl>T to bring up the type search window was very helpful using this I was able to see what resources were causing the problem (i.e. any resource that is also included in the JDK, in my case it was the ErrorHandler in the xml-apis jar). Type the name of one of the resources giving a "cannot be resolved to type" to see the name of the jar file, in my case the jar is xml-apis-1.4.01.jar.
All of this is shown in the screen shot below (click on the image to get a cleaner view).
Finding the Dependency that contains the offending jar
We can now use the information from https://www.eclipse.org/forums/index.php/t/1110036/ to find the dependency in our pom.xml file that contains the offending resource.
Open the pom.xml file in Eclipse and select the "Dependency Hierarchy". In the filter type the name of the jar file we found in the previous step (in my case it was xml-apis).
This will pull up the dependencies creating the problem. A screen shot of the Dependencies Hierarchy filtered for "xml-apis". From this we can see the offending dependencies in our pom.xml file are xercesImpl and xlsx-streamer.
Solving the problem
We can now add exclusions to these dependencies that will resolve the problem as shown below.
<dependency>
<groupId>com.monitorjbl</groupId>
<artifactId>xlsx-streamer</artifactId>
<version>2.1.0</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.12.0</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
And this fixes the current problem.
For anyone who suffer with this problem when refering to the org.w3c or javax.xml imports, be careful with this one module dependency: xml-apis it conflicts with java default xml classes.
One big project who references it is called DynamicJasper
Here's the image of my app
It seems to me the real problem here is that the JDK (in my case, JDK-19) has org.w3c.dom embedded in it, so everything else that was doing the correct thing by referencing libraries from external-lib, rather than embedding is now broken. I removed xml-apis and xerces, but it still complains about org.w3c.dom. the only place it is referenced in my project is the JDK.
Removing jar files, (xml-apis.jar and xerces_2_5_0.jar) Does not fix the issue. I cannot remove batik, project depends upon it.
I have a standard Java build, no maven. There is no decompiling/removing a valid reference that can be done with 3rd party software like batik.
Any suggestions on how to remove the embedded org.w3c.dom from JDK-19 so I can build?
I had this problem with the Stanford Core NLP package. As mentioned above adding an exclusion in the pom.xml solved the problem:
<dependency>
<groupId>edu.stanford.nlp</groupId>
<artifactId>stanford-corenlp</artifactId>
<version>4.5.2</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
First of all, make sure your pom is actually correct by running
mvn install
if that works, and eclipse still complains look at build path and find the library it is holding onto that is not in your pom.
Sometimes I just
rm .classpath
rm -rf .settings
rm -rf project
mvn eclipse:clean eclipse:eclipse
When referencing simple .jar files, Eclipse shows an error stating:
The package java.awt is accessible from more than one module: <unnamed>, java.desktop
This happens for instance when javax.awt or javax.swing is included in the .jar files.
The simplest example would be the following:
package test;
import javax.swing.JDialog;
public class Test {
public static void main(String[] args) {
new JDialog();
}
}
Adding a .jar file to the classpath with only the folder structure javax/swing (no files needed) will cause the error to appear. I'm using JDK 10/12 (neither works). Setting the compiler compliance to 1.8 makes the whole thing work again.
On another machine with Eclipse 2018-09 this works with compiler compliance set to 10.
I'm on Eclipse 2019-03, on a (for testing purposes) freshly installed Eclipse 2018-09 it works fine. Why?
Edit June/2020 (Solution)
As the answers correctly stated, this is a restriction built into Java ages ago and only recently was forced upon us. I came into contact with it while migrating a big project with dozens of dependencies to Maven. There were libraries from around the year 2000! There were 'meta libraries' which consisted of several libraries packaged together.
So there was no other way than to identify what was still needed (into the trash with the rest!), update libraries which violate the rules or find replacements for them. This took me many, many hours.
In the end it worked out and we've got a nice Maven project to work with.
This is caused by
a JAR on the Classpath that contains the package java.awt that also exists in the system library but the
JRE System Library is on the Modulepath
In the Java Platform Module System (JPMS) it is not allowed to use the same package in more than one module. If the Modulepath and the Classpath is used, everything on the Classpath is handled as the <unnamed> module (in your case the package java.awt exists in the system module java.desktop and also via the JAR on the Classpath in the module <unnamed>).
Since the JRE System Library cannot be moved from the Modulepath to the Classpath (see this answer by Stephan Herrmann for details), you only have the following options:
Set the compiler compliance to 1.8 (as you already mentioned)
Rebuilt the JAR to avoid Java system library package names inside the JAR (if reflection is used, additional code changes may be necessary):
If you have the source code, change the package names (e.g. change the package and subpackae java to java_util and javax to javax_util) and recreate the JAR
If you have only the .class files you have to decompile the .class files first
Since I'll bet lots of people will be running into this problem with modular Java, I'll help and give the real answer.
This error happens when
you have a dependency in your project
that contains code
using packages
that are also in the modules
being referenced by your project
If your project has set the source compatibility to something like Java 12, it will start enforcing the rule, that has been there all along in Java:
"Don't use packages that belong to the JDK in your own code."
Unfortunately, lots of developers and vendors have done that over the years. Can't do that anymore.
If you set your project to Java 12 source compatibility, Eclipse adds the JDK modules which include everything "java.*" and "javax.*" and even "jdk.*", "org.w3c.*". These packages may be in use by your dependencies or their transitive dependencies.
How to fix
You need to:
look at which package its complaining about
and expand the "Projects and External Dependencies" node in the Package Explorer.
Find out which dependency is using that package.
Then you can simply exclude that dependency from your project.
Or you could get the source of that dependency, if available, and rebuild the jar with changed packages. Otherwise you have to remove that dependency and find a replacement for that technology. Pain huh?
If its a transitive dependency you can often just exclude it. Here is an example of that for Gradle based projects.
GradleConfig.xml:
configurations {
all*.exclude group: 'xml-apis'
}
In my case, it was because I included a dependency (Apache Tika) in the POM.xml file.
I had to force the exclusion of the module that contained the classes with errors while imported at that dependency:
<dependency>
<groupId>org.apache.tika</groupId>
<artifactId>tika-parsers</artifactId>
<version>1.24.1</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
It worked for me that way.
I found a simple solution to troubleshoot this in Eclipse. Hit Ctrl + Shift + T in Eclipse to open the Open Type prompt. Then type the name of the package that is causing the issue. For me, it was org.w3c.dom. Now the search results will show all the locations from where this package is being loaded. Remove every JAR from the classpath that comes in the result other than the JDK 11 library.
My project being a legacy one, I had to remove a lot of JARs from the build path. Also, my project does not use Maven. So removing the JARs was a fairly straightforward step. The steps might vary for other build tools like ANT, Maven, Gradle, etc. I have just explained the troubleshooting steps above.
See also: The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml where I answered:
Disappointingly I don't see any compiler flags to show what jar the problem is with
Even -Xlint:module doesn't seem to show up anything useful and eclipse doesn't shed any light on the issue
Instead to find where java.awt comes from I've been using this script:
mvn dependency:copy-dependencies -DincludeScope=test -DoutputDirectory=deps
for i in deps/*.jar; do if unzip -l $i| grep -q java.awt; then echo $i; fi ; done
Strictly you don't have to specify the scope test as that's the default but I've included it as you might want to use compile instead
I think my flavour of the problem might be useful.
I got this error for classes under javax.xml.stream, by old Maven projects that depend on artifacts like xml-apis, stax-api, or geronimo-stax-api.
Technically, the problem is what others have already said: those artifacts expose the javax.xml.* package without any awareness of Java modules (they were invented later), so the package is automatically assigned to the unnamed module, which conflicts with the same package being included in the JDK's most recent versions, where the package has its own module name, and therefore the same package results in two different modules, which is forbidden.
That said, the practical solution is essentially to work with Maven exclusions to remove those dependencies from your project and let it use the JDK version instead (or, of course, remove them as direct dependencies, if that's your case). Use the equivalent if you're working with another build system.
In theory, the more recent flavours of these packages offered by the JDK might be non backward-compatible, in practice, I doubt such JSR specifications changed much over the years and so far, I haven't seen any issue with their replacement.
Since this is ranks quite high on Google I'm going to drop this here in case it's helpful for someone.
I've found some interesting behaviour with Java 11 and the xmlbeans library. The xmlbeans library is a transitive dependency of Apache POI, a very popular library for working with Microsoft Office documents, it is used to handle the internal XML structures of the newer Office formats. I've tested it with Apache POI 3.9 and it works perfectly fine, despite the error shown by Eclipse. So, I guess in Java 11 this rule it's not fully enforced.
For Apache POI version 5.0.0 using Maven, in the pom.xml:
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi</artifactId>
<version>5.0.0</version>
</dependency>
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi-ooxml</artifactId>
<version>5.0.0</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
Fixed: "The package javax.xml.parsers is accessible from more than one module"
I met a similar issue with the eclipse IDE while upgrading JDK from 1.8 to 11, "The package org.w3c.dom is accessible from more than one module: , java.xml". upgrading eclipse from 2019 to 2021 and setting system JDK home to 11 does not solve it. I don't think it's caused by "org.w3c.dom" existing in different jars of the classpath,dut to "Order and Export" should ordered the search sequence.
After several hours of searching and investigating, this issue is fixed by setting the Java Compiler - Compiler compliance level to 1.8(default is 11).
You can do what other people suggest which is to exclude xml-apis which worked fine with me, but if your are using and an old jaxb-api replace them with jakarta.xml.bind-api:
<dependency>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>2.3.3</version>
</dependency>
and of course upgrade your jaxb-impl to match the same api:
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.3.3</version>
</dependency>
Steps below helped me,
Right click Eclipse project > Properties > Java Build Path
In Libraries tab, remove all the external jar files under Modulepath and add them under Classpath (you can just select all the jars and drag them under Classpath)
Click Apply and Close
Hope it help you too.
Wow, this was a tough one!
Some helpful tips (a summary of my journey through this maze):
This started when I migrated from Java 1.8 to 11.0.11
Right out of the gate this caused problems. I needed to change the syntax for how to specify the Java version for the maven build plug in as shown below:
Before
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
After
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<release>11</release>
</configuration>
</plugin>
After that, everything compiled at a command prompt. However, when opening the project in Eclipse, I got a bunch of errors as shown in the next section.
Getting "<class> cannot be resolved to a type" errors
When I got errors in Eclipse and not at the command line I immediately started looking at configuration settings in Eclipse to no avail. After some googling I came to this post. The post at https://www.eclipse.org/forums/index.php/t/1110036/ was also very helpful.
Finding what resources were the problem
The answer to this post by #Anu suggesting using <shift><ctrl>T to bring up the type search window was very helpful using this I was able to see what resources were causing the problem (i.e. any resource that is also included in the JDK, in my case it was the ErrorHandler in the xml-apis jar). Type the name of one of the resources giving a "cannot be resolved to type" to see the name of the jar file, in my case the jar is xml-apis-1.4.01.jar.
All of this is shown in the screen shot below (click on the image to get a cleaner view).
Finding the Dependency that contains the offending jar
We can now use the information from https://www.eclipse.org/forums/index.php/t/1110036/ to find the dependency in our pom.xml file that contains the offending resource.
Open the pom.xml file in Eclipse and select the "Dependency Hierarchy". In the filter type the name of the jar file we found in the previous step (in my case it was xml-apis).
This will pull up the dependencies creating the problem. A screen shot of the Dependencies Hierarchy filtered for "xml-apis". From this we can see the offending dependencies in our pom.xml file are xercesImpl and xlsx-streamer.
Solving the problem
We can now add exclusions to these dependencies that will resolve the problem as shown below.
<dependency>
<groupId>com.monitorjbl</groupId>
<artifactId>xlsx-streamer</artifactId>
<version>2.1.0</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.12.0</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
And this fixes the current problem.
For anyone who suffer with this problem when refering to the org.w3c or javax.xml imports, be careful with this one module dependency: xml-apis it conflicts with java default xml classes.
One big project who references it is called DynamicJasper
Here's the image of my app
It seems to me the real problem here is that the JDK (in my case, JDK-19) has org.w3c.dom embedded in it, so everything else that was doing the correct thing by referencing libraries from external-lib, rather than embedding is now broken. I removed xml-apis and xerces, but it still complains about org.w3c.dom. the only place it is referenced in my project is the JDK.
Removing jar files, (xml-apis.jar and xerces_2_5_0.jar) Does not fix the issue. I cannot remove batik, project depends upon it.
I have a standard Java build, no maven. There is no decompiling/removing a valid reference that can be done with 3rd party software like batik.
Any suggestions on how to remove the embedded org.w3c.dom from JDK-19 so I can build?
I had this problem with the Stanford Core NLP package. As mentioned above adding an exclusion in the pom.xml solved the problem:
<dependency>
<groupId>edu.stanford.nlp</groupId>
<artifactId>stanford-corenlp</artifactId>
<version>4.5.2</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
First of all, make sure your pom is actually correct by running
mvn install
if that works, and eclipse still complains look at build path and find the library it is holding onto that is not in your pom.
Sometimes I just
rm .classpath
rm -rf .settings
rm -rf project
mvn eclipse:clean eclipse:eclipse
On various projects I've been working on, I've seen diferent ways of specifying dependencies versions. On some projects, the package version is written on the same dependency declaration:
<dependency>
<groupId>org.apache.myfaces.extensions.validator.validation-modules</groupId>
<artifactId>myfaces-extval-property-validation</artifactId>
<version>2.0.7</version>
<scope>compile</scope>
</dependency>
On others, a property is used, as in:
<dependency>
<groupId>org.apache.myfaces.extensions.validator.validation-modules</groupId>
<artifactId>myfaces-extval-property-validation</artifactId>
<version>${versions.extval}</version>
<scope>compile</scope>
</dependency>
For multimodule projects, I can see a clear benefit in declaring versions on the parent pom to avoid duplication (and the potential confusion and errors that come with it), but on single module applications, would there be a benefit to use such a level of indirection?
What would be a best practice for this and why?
Thanks a lot :)
With a version property you can override it on the command line whereas with a fixed version you cannot.
So you can recompile your project with a newer version just by specifying it on the command line.
mvn -Dversions.extval=2.0.8 clean package
Or something.
apart from that, mostly used on multi-projects, and although there you have the dependency management section as well for versions.
I use the maven-enforcer-plugin to check for dependency convergence issues. A typical output would be:
[WARNING] Rule 1: org.apache.maven.plugins.enforcer.DependencyConvergence failed
with message:
Failed while enforcing releasability the error(s) are [
Dependency convergence error for junit:junit:3.8.1 paths to dependency are:
+-foo:bar:1.0-SNAPSHOT
+-ca.juliusdavies:not-yet-commons-ssl:0.3.9
+-commons-httpclient:commons-httpclient:3.0
+-junit:junit:3.8.1
and
+-foo:bar:1.0-SNAPSHOT
+-junit:junit:4.11
]
Seeing this message, I would normally "solve" it by excluding the transitive dependency, e.g.
<dependency>
<groupId>ca.juliusdavies</groupId>
<artifactId>not-yet-commons-ssl</artifactId>
<version>0.3.9</version>
<exclusions>
<!-- This artifact links to another artifact which stupidly includes
junit in compile scope -->
<exclusion>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</exclusion>
</exclusions>
</dependency>
I'd like to understand whether this is truly a fix and the risks involved in excluding libraries in this fashion. As I see it:
The "fix" is normally safe, provided I'm choosing to use the newer version. This relies on the library authors maintaining backwards compatibility.
There is typically no impact on the Maven build (since the nearer definition wins), however by excluding the dependency I'm telling Maven that I know about this problem and thus appeasing the maven-enforcer-plugin.
Are my thoughts correct and is there an alternative way of handling this issue? I'm interested in answers that focus on the general case - I realise the junit example above is a little strange.
We all agree that JUnit should never be set to another scope than test. Generally speaking I don't think either that there is another solution than excluding the unwanted dependency, so we all agree that your are right to do it.
A SIMPLE CASE :
As Andreas Krueger says, there may be a risk with versions (I actually encountered it). Let say that the project's dependencies are the following:
+-foo:bar:1.0-SNAPSHOT
+-group1:projectA:2.0
+-group2:projectB:3.8.1
+-group2:projectB:4.11
Note that it is only a mere simplification of your case. Seeing this dependency tree, you would exclude the dependency projectB given by projectA :
<dependency>
<groupId>group1</groupId>
<artifactId>projectA</artifactId>
<version>2.0</version>
<exclusions>
<exclusion>
<groupId>group2</groupId>
<artifactId>projectB</artifactId>
</exclusion>
</exclusions>
</dependency>
After packaging the project with maven, the remaining dependency would be group2-someProjectB-4.11.jar, version 4.11 and not 3.8.1. Everything would be fine and the project would run without encountering any problem at all.
Then, a while after, let say that you decide to upgrade to the next version of project A, version 3.0 which adds new great features :
<dependency>
<groupId>group1</groupId>
<artifactId>projectA</artifactId>
<version>3.0</version>
<exclusions>
<exclusion>
<groupId>group2</groupId>
<artifactId>projectB</artifactId>
</exclusion>
</exclusions>
</dependency>
The problem is that you are not aware yet that projectA version 3.0 also have upgraded its dependency projectB to version 5.0 :
+-foo:bar:1.0-SNAPSHOT
+-group1:projectA:3.0
+-group2:projectB:5.0
+-group2:projectB:4.11
In that case, the exclusion you would have made a while ago excludes projectB version 5.0.
However, projectA version 3.0 needs the improvements from project B version 5.0. Because of the exclusion, after packaging the project with maven, the remaining dependency would be group2-someProjectB-4.11.jar, version 4.11 and not 5.0. At the moment you use any of projectA's new features, the program wouldn't run correctly.
WHAT WAS THE SOLUTION ?
I encountered this problem in a Java-EE project.
A team developped database services. They packaged it as projectA. Each time they updated the services, they also updated a file listing all their current dependencies and the current versions.
ProjectA was a dependency for the Java-EE project I was working on. Each time the service-team updated ProjectA, I also checked the versions' updates.
In fact, there is no harm in excluding a dependency. But each time you update a dependency where an exclusion has been set, You have to check :
if this exclusion still makes sense.
if you need to upgrade the version of the excluded dependency in your own project.
I guess maven exclusions are like kitchen knifes. It's sharp, cuts vegetables with no effort, but requires care when handling it...
If JUnit as an artifact is coming through as a dependency in compile scope, it is a bug of one of your libraries, here: ca.juliusdavies.
JUnit should always be included in test scope. Thus, it is not packed into the produced .jar, .war or .ear file, on successful build.
Generally speaking, there is no harm in excluding already included dependencies, as when library 1 and library 2 share one common dependency.
The only problem, of course, that can occur, is when library 1 and library 2 include different versions of the same dependent artifact. This can cause run-time errors, when the features of the library have changed.
Fortunately, this is not often the case, unless the difference in the version numbers is great. In general, it is advisable to include the latest dependency version and exlude the older one. This is most of the time viable.
If not, check wheter there are updates to the first-level dependencies of your project.