Unwanted libs(cglib and asm) in WAR file

Old Forum
1

Hi guys,

I’m using default war plugin to obtain war file.

But for reason I don’t know generated war contains two unlisted in dependencies libs: asm-3.1.jar and cglib-2.2.1-v20090111.jar And when using maven configured with the same dependencies this libs aren’t present in war file.

So, to keep it short: why is this happening?

2

Without a reproducible example, that’s impossible to say. Run ‘gradle dependencies’ and check where the unwanted dependencies come from.

3

Ok. Found it.

+--- com.google.inject:guice:3.0 [default]
|
  +--- javax.inject:javax.inject:1 [compile,master,runtime]
|
  +--- aopalliance:aopalliance:1.0 [compile,master,runtime]
|
  \--- org.sonatype.sisu.inject:cglib:2.2.1-v20090111 [compile,master,runtime]
|
       \--- asm:asm:3.1 [compile,master,runtime]

Then why this libs ale present is in war builded by Gradle but is not in mvn’s one?

4

Hard to say. Given the POMs of ‘guice’ and ‘cglib’, I see no reason not to include ‘cglib’ and ‘asm’. Maybe the Maven build selects a different version of ‘guice’ (conflict resolution works differently in Maven). If you don’t want ‘cglib’ and ‘asm’, you can always exclude them in the build script.

5

We just run into the same problem. The guice pom has a profile named “guice.with.jarjar”. When this profile is active (default), the cglib dependency is optional. Gradles maven dependency resolver seems to ignore this. When you run a maven project with the guice dependency and deactivate the profile

mvn dependency:tree -Dguice.with.jarjar=false

you get the cglib and asm dependencies:

\- com.google.inject:guice:jar:3.0:compile
    +- javax.inject:javax.inject:jar:1:compile
    +- aopalliance:aopalliance:jar:1.0:compile
    \- org.sonatype.sisu.inject:cglib:jar:2.2.1-v20090111:compile
       \- asm:asm:jar:3.1:compile
6

That’s correct. Gradle doesn’t currently honor Maven profiles when resolving. (It’s strongly discouraged to have profiles in published POMs, even in Maven land.) I’m pretty sure there is a JIRA for it, though. I think that supporting the default profile would be a good step forward.