Jar files are NOT included under WEB-INF\lib by war task

Help/Discuss
1

Hi,

I migrated a multi-module Spring Boot project, built using Maven to Gradle 6.4.1
But the output is strange.

Project consists of a web-project in which I have the ‘war’ plugin and the WAR task to (only to specify the .war file name)

war {
archiveName “${projectName}.war”
}

The other modules of the project are for respective tiers
(1)client facing rest-end-points,
(2) business and
(3) common.

With gradle I am not able to get standard libraries like log4j, commons-io, lang, gson, reast-easy-client etc bundled into the WAR (under WEB-INF\lib)

With Gradle these expected jars are NOT bundled into the WAR as opposed to a Maven.

They however could be located them insie a zip, under \build\distributions.

\build\distributions<web-project>-SNAPSHOT.zip<web-project>-SNAPSHOT\lib

Do I need to have a more explicit WAR task?

thank you

2

The war task doesn’t need to do anything explicitly with the libraries, but your other modules do need to be dependencies of the project building the WAR file.

3

Thank you.
After fixing the build.gradle files in other sub-projects, carefully - taking care to avoid circular dependency - I could get a bigger generated .war.

But really big.

The WEB-INF\lib folder
now includes probably transitive dependencies like - aether-api-1.0.0.v20140518.jar,
and many aether*.jar, apiguardian-api-1.0.0.jar, arquillian-config-api-1.4.0.Final.jar, many arquillian*.jar

Could this be caused by the
dependencies {
implementation “name.of.dependency”
instead of
compile “name.of.dependency”
}

ALSO versions of these transitive dependencies differ between maven-built war and gradle-built war.
Example
classmate-1.0.0.jar (in maven) and classmate-1.1.0.jar (in gradle)
commons-codec-1.10.jar (in maven) and commons-codec-1.11.jar (in gradle)
commons-io-2.1.jar (in maven) and commons-io-2.2.jar (in gradle)
and so on for
commons-lang3, hibernate-validator, httpcore, httpclient, jackson**

thank you.

4

It looks like you’re including everything in your implementation, compile or runtimeOnly configurations. I presume arquillian is a test dependency, in which case it should be in a testImplementation or testRuntimeOnly configuration. I’m sure your Maven setup is similar.

5

S Bufton, Thank you. I did required corrections and the size reduced.

However, I am also looking for why

versions of these transitive dependencies differ between maven-built war and gradle-built war.
Example
classmate-1.0.0.jar (in maven) and classmate-1.1.0.jar (in gradle)
commons-codec-1.10.jar (in maven) and commons-codec-1.11.jar (in gradle)
commons-io-2.1.jar (in maven) and commons-io-2.2.jar (in gradle)
and so on for
commons-lang3, hibernate-validator, httpcore, httpclient, jackson**

thanks

6

For transitive dependencies, Maven has a questionable strategy to decide which version of a transitive dependency to use. Maven uses a “nearest definition wins” strategy. So the definition in the pom.xml which is “nearest” to your pom.xml will win. In my opinion this is a terrible strategy, Gradle does not attempt to replicate this wierd behavior.

Instead, Gradle has a proper resolution implementation where build authors can force versions, apply rules etc. By default, Gradle will pick the largest requested version if two (or more) versions of a dependency are specified in the dependency tree which is likely causing the differences