CODEWITHSUNDEEP
javamavenintellij-idea
badunk
badunk

Reputation: 4350

Intellij build different from maven build

When I compile an uber jar from the command line via mvn package and execute with java -jar target/my-jar.jar, it fails with some dependencies conflicts.

When I execute from run/debug configuration, using Intellij's make, everything is fine!

Is there something different about Intellij's classpath? How would I go about figuring out the differences between the two builds?

Upvotes: 1

Views: 1598

Answers (1)

badunk
badunk

Reputation: 4350

I figured it out myself and learned a couple of things along the way. The problem turned out to be my maven shade plugin which was using

<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>

Even if you exclude transitive dependencies religiously, that transformer will still concatenate classes defined transitively and can cause issues with hk2 not finding the class it needs to inject dependencies. I was excluding some classes in order to prevent my application from running both Jersey 1 and Jersey 2. Removing that line fixed things for me and matched the behavior in Intellij.

Some potential differences between the artifact produced by mvn package and running a build with Intellij:

  • Intellij does not product a jar and thus, no META-INF directory. When using jersey and maven shade plugin, the META-INF/services directory is often scanned by the hk2 dependency for dependency injection.
  • Making a build in Intellij does not go through the maven lifecycle. If you rely on a particular maven plugin or build step to run your application, you'll have to have it execute a maven lifecycle step instead of the IDE's make.
  • There are slight scoping differences between Intellij (currently version 15) and maven. I discovered this by comparing mvn dependency:list -Dsort=true and sorting the screen in Project Settings > modules > {your module} > dependencies (tab).
  • There were some transitive dependencies found by maven that weren't in Intellij and vice versa. I used both dependency:list and dependency:tree -Dincludes=the.groupIid:the.artifact to track down where some transitive dependencies came from.

Upvotes: 2

Related Questions