War contains jars which are not among runtime dependencies

Old Forum
1

Hello,

Speaking of ‘war’ task the userguide claims: “All the dependencies of the runtime [11] configuration are copied to WEB-INF/lib”

What I see is that there are jars in my war that are not listed by the ‘depenedencies’ task, but somehow present in war.classpath.

The project, those dependencies come from has configurations as follows: - there is one “provided” which serves only for local code generation (by axis2-ant-plugin which brings in a lot others transitively) - and added to ‘compile’ a carefully selected set from the above that involves setting transitive = false for some

Doing in war: classpath = configurations.runtime gives the same result.

I’ve been struggling with finding a workaround for exclusion, still no success.

Any solution to either the original problem or for the workaround is appreciated.

Zsolt

2

Can you provide a self-contained reproducible example demonstrating the problem? Otherwise it will be difficult to help. Instead of ‘transitive = false’, try the ‘@jar’ notation (e.g. ‘commons-httpclient:commons-httpclient:3.0@jar’).

3

Hello Peter,

I put a minimalistic project package under: http://depositfiles.com/files/aitwphtrr Perhaps it could be cut further, but I wanted to retain some characteristics of my original project.

Running ‘dependendencies’ on modB will display war’s classpath too.

Thanks! Zsolt

4

I cannot download it. Please upload to a more credible site (e.g. GitHub).

5

Hm, I checked beforehand and worked, but OK here it is: https://github.com/tinca/gradle-trial

6

Except for ‘modB’'s own code, I cannot find any artifacts that are on the war class path but not on the ‘runtime’ configuration. Note that ‘runtime’ extends from ‘compile’, which means that the ‘runtime’ configuration includes all artifacts from the ‘compile’ configuration.

7

Here is mine, shpwing only a snippet from the war’s classpath.

$ gradle modB:dependencies …

usr/home/kuti/.gradle/caches/artifacts-8/filestore/org.apache.geronimo.specs/geronimo-activation_1.1_spec/1.0.2/jar/3efc3aadfaf8878060167e492c03fdafb905ae01/geronimo-activation_1.1_spec-1.0.2.jar:/usr/home/kuti/.gradle/caches/artifacts-8/filestore/jaxen/jaxen/1.1.1/jar/9f5d3c5974dbe5cf69c2c2ec7d8a4eb6e0fce7f9/jaxen-1.1.1.jar:/usr/home/kuti/.gradle/caches/artifacts-8/filestore/org.apache.geronimo.specs/geronimo-stax-api_1.0_spec/1.0.1/bundle/1c171093a8b43aa550c6050ac441abe713ebb4f2/geronimo-stax-api_1.0_spec-1.0.1.jar

… runtime - Classpath for running the compiled main classes. — gradle-trial:modA:0.1 [default]

±-- org.apache.axis2:axis2:1.6.1 [default]

±-- org.apache.axis2:axis2-kernel:1.6.1 [default]

±-- org.apache.ws.commons.axiom:axiom-api:1.2.12 [default]

±-- org.apache.ws.commons.axiom:axiom-impl:1.2.12 [default]

±-- org.apache.neethi:neethi:3.0.1 [default]

±-- wsdl4j:wsdl4j:1.6.2 [default]

±-- org.apache.ws.commons.schema:XmlSchema:1.4.7 [default]

±-- org.apache.geronimo.specs:geronimo-javamail_1.4_spec:1.6 [default]

±-- org.apache.axis2:axis2-transport-http:1.6.1 [default]

|

±-- org.apache.axis2:axis2-kernel:1.6.1 [compile,runtime,master] (*)

|

— org.apache.httpcomponents:httpcore:4.0 [compile,master,runtime]

±-- org.apache.axis2:axis2-transport-local:1.6.1 [default]

|

— org.apache.axis2:axis2-kernel:1.6.1 [compile,runtime,master] (*)

±-- commons-httpclient:commons-httpclient:3.1 [default]

|

±-- commons-codec:commons-codec:1.2 [compile,master,runtime]

|

— commons-logging:commons-logging:1.1.1 [compile,master,runtime]

— org.apache.woden:woden-api:1.0M9 [default]

— org.apache.ws.commons.schema:XmlSchema:1.4.7 [compile,runtime,master] (*)

For instance, geronimo jars, except of javamail, should not be in the CP, should they?

A fresh cache gives the same.

8

Maybe it’s a problem with the output of ‘gradle dependencies’ (but then you don’t show the compile dependencies). A simple way to check is to compare with the output of:

task showRuntimeDeps << {
  configurations.runtime.each { println it }
}
9

The output of runtime.each does show the “excess” jars.

A minimal case that show this by declaring the following dependencies: - axis-kernel, transitive = false

  • axis-transport-http, transitive = true (depends on axis-kernel)

  • Either ‘dependencies’ task misses to list transitive dependencies of axis-kernel coming from ‘transport’ or - construction of classpath fails to ignore dependencies that were already marked as non-transitive

I would be inclined to say the latter, although the same reasoning for and against it could be applied :frowning:

10

I assume you are talking about the following (please don’t leave us guessing and always provide the real code):

dependencies {
  compile("org.apache.axis2:axis2-kernel:1.6.1") { transitive = false }
   compile("org.apache.axis2:axis2-transport-http:1.6.1") { transitive = true }
}

Here the expected (and actual) behavior is that ‘compile’ contains all of ‘axis2-kernel’'s dependencies. These dependencies are brought in transitively via ‘axis2-transport-http’. The fact that you also explicitly add ‘axis2-kernel’ (without its dependencies) won’t make a difference.

The fact that ‘gradle dependencies’ doesn’t reflect this reality is a bug, possibly carried over from Ivy.

11

Hello Peter,

I am sorry for omitting code, I just didn’t want to repeat that was already in the github example project.

Thank you for the explanation and your attention.

Zsolt

12

Your Github example project is much more complicated than this and may be “failing” for different reasons. In particular, a configuration’s ‘transitive’ flag is only considered when resolving the configuration directly, but not when resolving another configuration that extends from it. This is an unfortunate carry-over from Ivy.