Maven dependency tree and pom dependencies - java

I would like to know all transitive dependencies of the following jar:
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>xmlbeans-maven-plugin</artifactId>
<version>2.3.3</version>
</dependency>
Moving a classic command to the pom.xml of the project's defining that dependency and inputting:
mvn dependency:tree
would show:
+- org.codehaus.mojo:xmlbeans-maven-plugin:jar:2.3.3:compile
| +- xml-resolver:xml-resolver:jar:1.2:compile
| +- org.apache.maven:maven-model:jar:2.0.6:compile
| +- org.apache.maven:maven-artifact:jar:2.0.6:compile
| +- org.apache.maven:maven-project:jar:2.0.6:compile
| | +- org.apache.maven:maven-settings:jar:2.0.6:compile
| | +- org.apache.maven:maven-profile:jar:2.0.6:compile
| | +- org.apache.maven:maven-artifact-manager:jar:2.0.6:compile
| | | +- org.apache.maven:maven-repository-metadata:jar:2.0.6:compile
| | | \- org.apache.maven.wagon:wagon-provider-api:jar:1.0-beta-2:compile
| | +- org.apache.maven:maven-plugin-registry:jar:2.0.6:compile
| | \- org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:compile
| | +- junit:junit:jar:3.8.1:compile
| | \- classworlds:classworlds:jar:1.1-alpha-2:compile
| +- org.apache.maven:maven-plugin-api:jar:2.0.6:compile
| +- org.apache.xmlbeans:xmlbeans:jar:2.4.0:compile
| | \- stax:stax-api:jar:1.0.1:compile
| \- org.codehaus.plexus:plexus-utils:jar:1.5.6:compile
I don't see the mojo-parent:
<groupId>org.codehaus.mojo</groupId>
<artifactId>mojo-parent</artifactId>
<version>21</version>
<packaging>pom</packaging>
At first glance it seems that the mvn command can show the dependencies which are not pom type.
Is there a way to show exactly every single file needed to keep a jar alive?
Thanks!

Actually it's hard to show files needed to 'keep a jar alive'. Your project can have some implicit dependencies.
You can run mvn dependency:analyze, it should show you unused dependencies.
But you have realize which of them you can freely remove. http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
I can also recommend if you don't want any surprises with transitive dependencies - use maven enforcer. You can ban all undeclared transitive dependencies.
http://maven.apache.org/enforcer/enforcer-rules/banTransitiveDependencies.html

Related

embedded-kafka scalatest ClassNotFoundException: scala.collection.GenTraversableOnce

New to Scala, I'm on step one of implementing a ScalaTest with https://github.com/embeddedkafka/embedded-kafka according to the second example at the top of that README:
import net.manub.embeddedkafka.EmbeddedKafka
import org.scalatest.matchers.should.Matchers
import org.scalatest.wordspec.AnyWordSpecLike
class MinimalTest extends AnyWordSpecLike with Matchers {
"runs with embedded kafka" should {
"work" in {
EmbeddedKafka.start()
1 + 1 shouldBe 2
// ... code goes here
EmbeddedKafka.stop()
}
}
}
Running this test, the failure is at a lower level than I am familiar with:
MinimalTest:
runs with embedded kafka
*** RUN ABORTED ***
java.lang.NoClassDefFoundError: scala/collection/GenTraversableOnce
at com.myorganization.api.MinimalTest.$anonfun$new$2(MinimalTest.scala:13)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.scala:18)
at org.scalatest.OutcomeOf.outcomeOf(OutcomeOf.scala:85)
at org.scalatest.OutcomeOf.outcomeOf$(OutcomeOf.scala:83)
at org.scalatest.OutcomeOf$.outcomeOf(OutcomeOf.scala:104)
at org.scalatest.Transformer.apply(Transformer.scala:22)
at org.scalatest.Transformer.apply(Transformer.scala:20)
at org.scalatest.wordspec.AnyWordSpecLike$$anon$3.apply(AnyWordSpecLike.scala:1076)
at org.scalatest.TestSuite.withFixture(TestSuite.scala:196)
at org.scalatest.TestSuite.withFixture$(TestSuite.scala:195)
...
Cause: java.lang.ClassNotFoundException: scala.collection.GenTraversableOnce
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
at com.myorganization.api.MinimalTest.$anonfun$new$2(MinimalTest.scala:13)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.scala:18)
at org.scalatest.OutcomeOf.outcomeOf(OutcomeOf.scala:85)
at org.scalatest.OutcomeOf.outcomeOf$(OutcomeOf.scala:83)
at org.scalatest.OutcomeOf$.outcomeOf(OutcomeOf.scala:104)
at org.scalatest.Transformer.apply(Transformer.scala:22)
at org.scalatest.Transformer.apply(Transformer.scala:20)
...
I suspect a mismatch of dependency versions, but can't spot it. Here's my relevant build.gradle contents:
plugins {
id 'java'
id 'scala'
}
task spec(dependsOn: ['testClasses'], type: JavaExec) {
main = 'org.scalatest.tools.Runner'
args = ['-R', 'build/classes/scala/test', '-o']
classpath = sourceSets.test.runtimeClasspath
}
dependencies {
compile 'io.confluent:kafka-streams-avro-serde:5.4.0'
compile 'io.github.embeddedkafka:embedded-kafka-streams_2.12:2.4.0'
compile 'io.github.embeddedkafka:embedded-kafka_2.12:2.4.0'
compile 'org.apache.avro:avro:1.9.1'
compile 'org.apache.kafka:kafka-clients:2.4.0'
compile 'org.apache.kafka:kafka-streams:2.4.0'
compile 'org.apache.kafka:kafka_2.13:2.4.0'
compile 'org.scala-lang:scala-reflect:2.12.6'
testCompile 'io.github.embeddedkafka:embedded-kafka-schema-registry_2.12:5.4.0' // match schema registry version
testCompile 'io.github.embeddedkafka:embedded-kafka-streams_2.13:2.4.0' // match kafka streams version
testCompile 'io.github.embeddedkafka:embedded-kafka_2.13:2.4.0' // match kafka version
testCompile 'org.scala-lang:scala-library:2.13.2'
testCompile 'org.scalatest:scalatest_2.13:3.1.2'
testImplementation 'junit:junit:4.11'
testRuntime 'org.pegdown:pegdown:1.4.2'
}
Gradle can indeed be a bit funny with transitive dependencies for Scala - in the sense that it will not automatically calculate a coherent set of versions.
The "missing" class scala/collection/GenTraversableOnce is part of the scala-library and is available in 2.12.x
So you should be able to fix this by:
a. Explicitly declaring the scala library version on your runtime classpath:
implementation group: 'org.scala-lang', name: 'scala-library', version: '2.12.6'
b. Checking all your other dependencies for 2.13 versions of the libraries (as #ShankarShastri suggested). Seems like embedded-kafka does have a 2.12 compatible build here: https://mvnrepository.com/artifact/io.github.embeddedkafka/embedded-kafka_2.12/2.5.0
Once you have done this, assuming your IDE is set up to sync with your build.gradle file, you should be able to look at the dependencies (declared and transitive) that gradle has calculated. If you still have problems, go through these manually and see if the org.scala-lang:scala-library library is missing or declared twice. If you have multiple declarations you can look at each library's dependencies in mvncentral.com .
N.B. the reason for step (a) is that you have scala artefacts in your 'compile' dependencies, so I assume that all your code (not just your test code) is using scala.
I can confirm the fix is validation dependencies. Or more technically check the test dependencies.
For me I upgraded my SpringBoot version which changed my spring-kafka-test version which intern included kafka 2.13.x which finally included scala libs.
I used mvn dependency:tree on my project's build file and searched for '2.12' to find where the old dependency was coming from. Example dependency tree (unrelated dependencies removed). Notice org.apache.kafka:kafka_2.11:jar:0.10.0.0 included as part of my.company.riptide.api:ness-logger:jar:1.0.0 but org.springframework.kafka:spring-kafka-test:jar:2.7.9 includes a newer version org.apache.kafka:kafka_2.13:jar:2.7.2
My solution was to exclude kafaka_2.11 from my ness-logger dependency like this:
<dependency>
<groupId>my.company.riptide.api</groupId>
<artifactId>ness-logger</artifactId>
<version>1.0.0</version>
<exclusions>
<exclusion>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka_2.11</artifactId>
</exclusion>
</exclusions>
</dependency>
Truncated output of mvn dependency:tree:
[INFO] +- my.company.riptide.api:ness-logger:jar:1.0.0:compile
[INFO] | +- org.springframework.boot:spring-boot-starter-validation:jar:2.5.7:compile
[INFO] | | +- org.apache.tomcat.embed:tomcat-embed-el:jar:9.0.55:compile
[INFO] | | \- org.hibernate.validator:hibernate-validator:jar:6.2.0.Final:compile
[INFO] | | \- jakarta.validation:jakarta.validation-api:jar:2.0.2:compile
[INFO] | +- commons-io:commons-io:jar:2.7:compile
[INFO] | +- my.company.eis:ness-logging-package:jar:4.0.1:compile
[INFO] | | +- org.apache.avro:avro:jar:1.8.2:compile
[INFO] | | | +- org.codehaus.jackson:jackson-core-asl:jar:1.9.13:compile
[INFO] | | | +- org.codehaus.jackson:jackson-mapper-asl:jar:1.9.13:compile
[INFO] | | | +- com.thoughtworks.paranamer:paranamer:jar:2.7:compile
[INFO] | | | \- org.tukaani:xz:jar:1.5:compile
[INFO] | | +- org.apache.avro:avro-compiler:jar:1.8.2:compile
[INFO] | | | +- org.apache.velocity:velocity:jar:1.7:compile
[INFO] | | | \- joda-time:joda-time:jar:2.7:compile
[INFO] | | +- org.apache.kafka:kafka_2.11:jar:0.10.0.0:compile
[INFO] | | | +- com.101tec:zkclient:jar:0.8:compile
[INFO] | | | \- org.scala-lang.modules:scala-parser-combinators_2.11:jar:1.0.4:compile
[INFO] | | \- com.netflix.hystrix:hystrix-core:jar:1.5.18:compile
[INFO] | | +- com.netflix.archaius:archaius-core:jar:0.4.1:compile
[INFO] | | \- io.reactivex:rxjava:jar:1.3.8:compile
[INFO] | +- org.springframework.boot:spring-boot-loader-tools:jar:2.5.7:compile
[INFO] | | \- org.apache.commons:commons-compress:jar:1.21:compile
[INFO] | \- my.company.riptide.springboot:graceful-shutdown:jar:1.0.2:compile
[INFO] +- org.springframework.kafka:spring-kafka:jar:2.7.9:compile
[INFO] | +- org.springframework:spring-messaging:jar:5.3.13:compile
[INFO] | +- org.springframework:spring-tx:jar:5.3.13:compile
[INFO] | +- org.springframework.retry:spring-retry:jar:1.3.1:compile
[INFO] | | \- javax.annotation:javax.annotation-api:jar:1.3.2:compile
[INFO] | +- org.apache.kafka:kafka-clients:jar:2.7.2:compile
[INFO] | | +- com.github.luben:zstd-jni:jar:1.4.5-6:compile
[INFO] | | +- org.lz4:lz4-java:jar:1.7.1:compile
[INFO] | | \- org.xerial.snappy:snappy-java:jar:1.1.7.7:compile
[INFO] | \- com.google.code.findbugs:jsr305:jar:3.0.2:compile
[INFO] +- junit:junit:jar:4.13.2:test
[INFO] | \- org.hamcrest:hamcrest-core:jar:2.2:compile
[INFO] +- io.cucumber:cucumber-spring:jar:7.0.0:test
[INFO] | \- org.apiguardian:apiguardian-api:jar:1.1.2:test
[INFO] +- io.cucumber:cucumber-core:jar:7.0.0:test
[INFO] | +- io.cucumber:cucumber-gherkin:jar:7.0.0:test
[INFO] | +- io.cucumber:cucumber-gherkin-messages:jar:7.0.0:test
[INFO] | +- io.cucumber:messages:jar:17.1.1:test
[INFO] | +- io.cucumber:tag-expressions:jar:4.0.2:test
[INFO] | +- io.cucumber:cucumber-expressions:jar:13.0.1:test
[INFO] | +- io.cucumber:datatable:jar:7.0.0:test
[INFO] | +- io.cucumber:cucumber-plugin:jar:7.0.0:test
[INFO] | +- io.cucumber:docstring:jar:7.0.0:test
[INFO] | +- io.cucumber:html-formatter:jar:17.0.0:test
[INFO] | \- io.cucumber:create-meta:jar:6.0.1:test
[INFO] +- org.springframework.kafka:spring-kafka-test:jar:2.7.9:test
[INFO] | +- org.apache.kafka:kafka-clients:jar:test:2.7.2:test
[INFO] | +- org.apache.kafka:kafka-streams:jar:2.7.2:test
[INFO] | | +- org.apache.kafka:connect-json:jar:2.7.2:test
[INFO] | | | \- org.apache.kafka:connect-api:jar:2.7.2:test
[INFO] | | \- org.rocksdb:rocksdbjni:jar:5.18.4:test
[INFO] | +- org.apache.kafka:kafka-streams-test-utils:jar:2.7.2:test
[INFO] | +- org.apache.kafka:kafka_2.13:jar:2.7.2:test
[INFO] | | +- org.apache.kafka:kafka-raft:jar:2.7.2:test
[INFO] | | +- com.fasterxml.jackson.module:jackson-module-scala_2.13:jar:2.12.5:test
[INFO] | | +- com.fasterxml.jackson.dataformat:jackson-dataformat-csv:jar:2.12.5:test
[INFO] | | +- net.sf.jopt-simple:jopt-simple:jar:5.0.4:compile
[INFO] | | +- com.yammer.metrics:metrics-core:jar:2.2.0:compile
[INFO] | | +- org.scala-lang.modules:scala-collection-compat_2.13:jar:2.2.0:test
[INFO] | | +- org.scala-lang.modules:scala-java8-compat_2.13:jar:0.9.1:test
[INFO] | | +- org.scala-lang:scala-library:jar:2.13.3:compile
[INFO] | | +- org.scala-lang:scala-reflect:jar:2.13.3:test
[INFO] | | +- com.typesafe.scala-logging:scala-logging_2.13:jar:3.9.2:test
[INFO] | | +- org.apache.zookeeper:zookeeper:jar:3.5.9:compile
[INFO] | | | +- org.apache.zookeeper:zookeeper-jute:jar:3.5.9:compile
[INFO] | | | +- org.apache.yetus:audience-annotations:jar:0.5.0:compile
[INFO] | | | \- io.netty:netty-transport-native-epoll:jar:4.1.70.Final:compile
[INFO] | | \- commons-cli:commons-cli:jar:1.4:test
[INFO] | +- org.apache.kafka:kafka_2.13:jar:test:2.7.2:test
[INFO] | \- org.junit.jupiter:junit-jupiter-api:jar:5.7.2:test
[INFO] | +- org.opentest4j:opentest4j:jar:1.2.0:test
[INFO] | \- org.junit.platform:junit-platform-commons:jar:1.7.2:test

Maven dependencies available in one project but not another

I have two projects that use identical pom files (one project is an earlier version of the second). The second project compiles fine and allows me to use all the dependencies defined in the pom in my project. However the first project does not, and it appears as though the dependencies are not even recognized by the project.
I looked in my local .m2 folder and see that the dependencies have been downloaded in their respective folders. I even see the mvn install output says it has included the dependency, e.g.:
Including com.fasterxml.jackson.core:jackson-core:jar:2.9.6 in the shaded jar.
And later...
com.fasterxml.jackson.core:jackson-databind:jar:2.9.6 already exists in destination.
I've tried mvn clean and the dependency is still not recognized. I've tried examining the contents of all of the pom files in the project and I can't see any difference between the two projects.
I'm convinced that there is something wrong with my project, but I'm not a maven expert. Any ideas of where to look for the problem?
Here's an example of one of the dependencies that is not recognized:
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.4</version>
<scope>compile</scope>
</dependency>
Here is my mvn dependency:tree ouput
[INFO] SwirldsProxy:SwirldsProxy:jar:0.0.1-SNAPSHOT
[INFO] +- SwirldsPlatform:platform:jar:0.0.1-SNAPSHOT:compile
[INFO] | +- SwirldsPlatform:fc:jar:0.0.1-SNAPSHOT:compile
[INFO] | | +- SwirldsPlatform:fcfs:jar:0.0.1-SNAPSHOT:compile
[INFO] | | | +- SwirldsPlatform:fcutil:jar:0.0.1-SNAPSHOT:compile
[INFO] | | | | +- SwirldsPlatform:abcl-swirlds:jar:0.0.1-SNAPSHOT:compile
[INFO] | | | | +- org.abcl:abcl-contrib:jar:1.4.0:compile
[INFO] | | | | +- org.apache.derby:derby:jar:10.12.1.1:compile
[INFO] | | | | \- org.beanshell:bsh:jar:2.0b5:compile
[INFO] | | | \- SwirldsPlatform:fcfs-dep-fasl:jar:0.0.1-SNAPSHOT:compile
[INFO] | | +- SwirldsPlatform:fcdb:jar:0.0.1-SNAPSHOT:compile
[INFO] | | | \- SwirldsPlatform:fcdb-dep-fasl:jar:0.0.1-SNAPSHOT:compile
[INFO] | | \- junit:junit:jar:3.8.2:compile
[INFO] | +- com.offbynull.portmapper:portmapper:jar:2.0.4:compile
[INFO] | | +- org.apache.commons:commons-lang3:jar:3.4:compile
[INFO] | | +- commons-io:commons-io:jar:2.5:compile
[INFO] | | \- org.apache.commons:commons-collections4:jar:4.1:compile
[INFO] | +- org.slf4j:slf4j-nop:jar:1.7.21:compile
[INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.7:compile
[INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.7:compile
[INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.9.6:compile
[INFO] | +- com.fasterxml.jackson.core:jackson-annotations:jar:2.9.0:compile
[INFO] | \- com.fasterxml.jackson.core:jackson-core:jar:2.9.6:compile
[INFO] +- com.google.code.gson:gson:jar:2.4:compile
[INFO] +- com.rabbitmq:amqp-client:jar:4.0.2:compile
[INFO] | \- org.slf4j:slf4j-api:jar:1.7.21:compile
[INFO] \- com.github.davidmoten:flatbuffers-java:jar:1.6.0.2:compile
Apache Maven 3.5.0 Maven
Java version: 1.8.0_144-1-redhat
UPDATE 8/30/2018
So I discovered some interseting behavior. My project location was under D:\SomeDirectory. I tried moving it to C:\AnotherDirectory and performed mvn install and bingo, the dependencies were now available to my project.
I'm assuming this has something to do with the maven/java installation location, however I find it strange that I saw no errors when trying to run the maven commands, even when the project was under a different root directory (D:) compared to maven/java (C:).
Any ideas?

java 9 unnamed module reads package [X] from both ... while debugging (with IntelliJ)

In my project I have a package that uses several 3rd party libraries. Let's have a look at the dependency tree:
[INFO] +- commons-logging:commons-logging:jar:1.2:compile
[INFO] +- org.apache.directory.studio:org.apache.commons.collections:jar:3.2.1:compile
[INFO] | \- commons-collections:commons-collections:jar:3.2.2:compile
[INFO] +- xerces:xercesImpl:jar:2.11.0:compile
[INFO] | \- xml-apis:xml-apis:jar:1.4.01:compile
[INFO] +- org.apache.cxf:cxf-rt-bindings-soap:jar:3.2.2:compile
[INFO] | +- org.apache.cxf:cxf-core:jar:3.2.2:compile
[INFO] | | +- com.fasterxml.woodstox:woodstox-core:jar:5.0.3:compile
[INFO] | | | \- org.codehaus.woodstox:stax2-api:jar:3.1.4:compile
[INFO] | | \- org.apache.ws.xmlschema:xmlschema-core:jar:2.2.3:compile
[INFO] | +- org.apache.cxf:cxf-rt-wsdl:jar:3.2.2:compile
[INFO] | | +- wsdl4j:wsdl4j:jar:1.6.3:compile
[INFO] | | \- org.ow2.asm:asm:jar:5.2:compile
[INFO] | \- org.apache.cxf:cxf-rt-databinding-jaxb:jar:3.2.2:compile
[INFO] +- org.apache.wss4j:wss4j-ws-security-common:jar:2.2.1:compile
[INFO] | +- org.slf4j:slf4j-api:jar:1.7.22:compile
[INFO] | +- org.apache.santuario:xmlsec:jar:2.1.1:compile
[INFO] | | \- commons-codec:commons-codec:jar:1.10:compile
[INFO] | +- org.opensaml:opensaml-saml-impl:jar:3.3.0:compile
[INFO] | | +- org.opensaml:opensaml-profile-api:jar:3.3.0:compile
[INFO] | | | \- org.opensaml:opensaml-core:jar:3.3.0:compile
[INFO] | | | \- io.dropwizard.metrics:metrics-core:jar:3.1.2:compile
[INFO] | | +- org.opensaml:opensaml-saml-api:jar:3.3.0:compile
[INFO] | | | +- org.opensaml:opensaml-xmlsec-api:jar:3.3.0:compile
[INFO] | | | \- org.opensaml:opensaml-soap-api:jar:3.3.0:compile
[INFO] | | +- org.opensaml:opensaml-security-impl:jar:3.3.0:compile
[INFO] | | | \- org.opensaml:opensaml-security-api:jar:3.3.0:compile
[INFO] | | | +- org.cryptacular:cryptacular:jar:1.1.1:compile
[INFO] | | | \- org.bouncycastle:bcprov-jdk15on:jar:1.55:compile
[INFO] | | +- org.opensaml:opensaml-xmlsec-impl:jar:3.3.0:compile
[INFO] | | \- net.shibboleth.utilities:java-support:jar:7.3.0:compile
[INFO] | | +- com.google.guava:guava:jar:19.0:compile
[INFO] | | \- joda-time:joda-time:jar:2.7:compile
[INFO] | +- org.opensaml:opensaml-xacml-impl:jar:3.3.0:compile
[INFO] | | \- org.opensaml:opensaml-xacml-api:jar:3.3.0:compile
[INFO] | +- org.opensaml:opensaml-xacml-saml-impl:jar:3.3.0:compile
[INFO] | | \- org.opensaml:opensaml-xacml-saml-api:jar:3.3.0:compile
[INFO] | +- org.jasypt:jasypt:jar:1.9.2:compile
[INFO] | \- org.apache.geronimo.javamail:geronimo-javamail_1.4_mail:jar:1.8.4:compile
[INFO] +- org.apache.wss4j:wss4j-ws-security-dom:jar:2.2.1:compile
[INFO] | \- net.sf.ehcache:ehcache:jar:2.10.4:runtime
[INFO] +- org.slf4j:slf4j-log4j12:jar:1.7.22:compile
[INFO] +- log4j:log4j:jar:1.2.17:compile
[INFO] \- org.testng:testng:jar:6.11:test
[INFO] +- com.beust:jcommander:jar:1.64:test
[INFO] \- org.yaml:snakeyaml:jar:1.17:test
Compiling and running works fine so far.
But when I what to start debugging with IntelliJ, I get a list of over 100 errors like:
Error:java: the unnamed module reads package org.opensaml.saml.config from both opensaml.saml.api and opensaml.saml.impl
Error:java: the unnamed module reads package javax.xml.datatype from both xml.apis and java.xml
Error:java: the unnamed module reads package javax.xml.transform.dom from both xml.apis and java.xml
....
This seems to be an error due to the new Java 9 module restrictions. But how to deal with here?
Both org.opensaml are part of wss4j-ws-security-common 2.2.1 (this is the last version, released in January 2018). opensaml.saml.api and opensaml.saml.impl are version 3.3.0 and both use org.opensaml.saml.config of the same version. So???
And why does "mvn compile" pass, but debugging with IntelliJ fails?
I had the same 100+ multititude of "ERROR: The unnamed module reads package javax.xml from both xml.apis and java.xml" in my Java 9 IntelliJ project too.
Except I would get them whenever I tried to run unit tests in IntelliJ. Everything worked perfectly building and testing with maven from the command line; just like you.
I was able to make my errors go away by...
1) Removing the following from the top-level pom of a multi-module project...
<dependency>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>1.4.01</version>
</dependency>
...
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>${javaee.api.version}</version>
<scope>provided</scope>
</dependency>
2) Right clicking the top-level pom in IntelliJ's project navigator, then select "Maven - Reimport"
3) Doing "Build -> Build module [myModule]" from the IntelliJ menu.
Just work out which maven artifacts contain the packages listed in your 100+"ERROR" messages. Then comment them out. Reimport. Then "Build module" from the menu. That worked for me anyway.
The artifacts I removed from the pom were copy/pasted in there speculatively from another project I used as a template. But luckily I don't need any of them.
This is a known IDEA bug. Please vote for https://youtrack.jetbrains.com/issue/IDEA-171320

Undefined trace method for Log4J

I am getting a weird compilation error in my Maven (version 3.1.0) project. I have added the following dependency to my POM:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
When I use the following code, I get a The method trace(String) is undefined for type Logger error.
import org.apache.log4j.Logger;
...
private static Logger logger = Logger.getLogger(Main.class);
...
logger.trace("message to be traced");
If i use e.g. debug instead of trace, though, the code compiles just fine.
What's might be wrong?
In case I have omitted some important information, please feel free to ask for it in comments. I will add them right away.
When I run the suggested mvn dependency:tree command, I get the following output.
biz.jezek:inscsdbdt:jar:1.0
+- com.sun.xml.ws:jaxws-rt:jar:2.1.3:compile
| +- javax.xml.ws:jaxws-api:jar:2.1:compile
| | \- javax.xml.bind:jaxb-api:jar:2.1:compile
| +- com.sun.xml.bind:jaxb-impl:jar:2.1.6:compile
| +- com.sun.xml.messaging.saaj:saaj-impl:jar:1.3:compile
| | \- javax.xml.soap:saaj-api:jar:1.3:compile
| +- com.sun.xml.stream.buffer:streambuffer:jar:0.7:compile
| | \- javax.activation:activation:jar:1.1:compile
| +- com.sun.xml.stream:sjsxp:jar:1.0:compile
| | \- javax.xml.stream:stax-api:jar:1.0:compile
| +- org.jvnet.staxex:stax-ex:jar:1.2:compile
| +- com.sun.org.apache.xml.internal:resolver:jar:20050927:compile
| \- org.jvnet:mimepull:jar:1.1:compile
+- log4j:log4j:jar:1.2.17:compile
+- biz.jezek:jdt:jar:1.0:compile
+- biz.jezek:utils:jar:1.0-SNAPSHOT:compile
| +- biz.jezek:dmsclient:jar:10.0.1:compile
| \- biz.jezek:umsjavaclient:jar:10.0.1:compile
+- com.microsoft:sqljdbc:jar:4:compile
+- commons-lang:commons-lang:jar:2.6:compile
+- org.aspectj:aspectjrt:jar:1.6.7:compile
+- junit:junit:jar:4.8.2:test (scope not updated to compile)
\- org.mockito:mockito-all:jar:1.8.4:test
Check isTraceEnabled() on your logger. This may allow you to see if you have enabled
log4j.rootLogger=TRACE
See Log4j | Updating the Log Level for the Appender as well

How to upgrade all dependencies to a specific version

I tried doing a mvn dependency:tree and I get a tree of dependencies.
My question is, My project depends on many modules which internally depends on many spring artifacts. There are a few version clashes. I want to upgrade all spring related libraries to say the latest one (2.6.x or above). What is the preferred way to do this?
Should I declare all the deps spring-context, spring-support (and 10 other artifacts) in my pom.xml and point them to 2.6.x ? Is there any other better method ?
[INFO] +- com.xxxx:yyy-jar:jar:1.0-SNAPSHOT:compile
[INFO] | +- com.xxxx:zzz-commons:jar:1.0-SNAPSHOT:compile
[INFO] | | +- org.springframework:spring-dao:jar:2.0.7:compile
[INFO] | | +- org.springframework:spring-jdbc:jar:2.0.7:compile
[INFO] | | +- org.springframework:spring-web:jar:2.0.7:compile
[INFO] | | +- org.springframework:spring-support:jar:2.0.7:compile
[INFO] | | +- net.sf.ehcache:ehcache:jar:1.2:compile
[INFO] | | +- commons-collections:commons-collections:jar:3.2:compile
[INFO] | | +- aspectj:aspectjweaver:jar:1.5.3:compile
[INFO] | | +- betex-commons:betex-commons:jar:5.5.1-2:compile
[INFO] | | \- javax.servlet:servlet-api:jar:2.4:compile
[INFO] | +- org.springframework:spring-beans:jar:2.0.7:compile
[INFO] | +- org.springframework:spring-jmx:jar:2.0.7:compile
[INFO] | +- org.springframework:spring-remoting:jar:2.0.7:compile
[INFO] | +- org.apache.cxf:cxf-rt-core:jar:2.0.2-incubator:compile
[INFO] | | +- org.apache.cxf:cxf-api:jar:2.0.2-incubator:compile
[INFO] | | | +- org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0-M1:compile
[INFO] | | | +- org.codehaus.woodstox:wstx-asl:jar:3.2.1:compile
[INFO] | | | +- org.apache.neethi:neethi:jar:2.0.2:compile
[INFO] | | | \- org.apache.cxf:cxf-common-schemas:jar:2.0.2-incubator:compile
UPDATE : I have removed the extra question about "\-" so my question is now what the subject asks for :)
End of that subtree. Nothing more than a fancy bit of ascii art - think as if its +-
There are two solutions:
The OSS way: Download the projects you depend on, migrate them to the latest version of Spring and send them a patch so everyone gets the new features
Overwrite the version of every dependency in your own POM.
Have you looked at the dependecyManagement tag? It allows you to specify the version number of each dependency a parent pom. All your other poms can then inherit the specified versions:
<properties>
<spring.version>2.5.6</spring.version>
</properties>
...
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring.version}</version>
</dependency>
<!-- more dependencies -->
</dependencies>
</dependencyManagement>
More information is available at the Introduction to the Dependency Mechanism.

Categories