Gradle Multiproject Build: How to include JAR of a WAR project into another WAR without creating pseudo projects

Question

I have two web apps A and B . B uses parts of code from A .

If I declare A as a dependency for B the A.war is included WEB-INF/lib of B.war

This kind of include is meaningless to the container.

The only solution I see is to change A to a Java project (JAR) and create a dummy web project (WAR) called A_WEB . Then declare A as dependency for A_WEB and B

However this will require me to meddle with the project structure. A big reason for choosing gradle was that it promised not to make the project adapat to the tool like maven does. So I hope there is a non messy way out of this.

Answer 1

How have you declared the dependency? I assume you have a multi-project build with subprojects A and B, both using the War plugin. I made an experiment using Gradle 2.4 and if I declare B/build.gradle like this:

apply plugin: 'war'

dependencies {
    compile project(':A')
}

then B.war contains WEB-INF/lib/A.jar . If you correctly follow conventions of Gradle War plugin (place web resources in A/src/main/webapp/ and code-related resources in A/src/main/resources/ ), then A.jar should contain what you want.

Alternatively, if you really need to hack something around, you can selectively copy things from A:

apply plugin: 'war'

war.dependsOn(':A:war')

war {
    from project(':A').sourceSets.main.output.classesDir
}

classesDir is an instance of java.io.File , so you may filter files as described in Gradle's tutorial on working with files .

However, if you write that " B uses parts of code from A ", this means your A actually contains a sub-project C which is the code shared both by A and B . You just don't accept the fact. What you are trying to do is to hack around and hide the dependency on C from anyone - instead of making it clear by extracting C as a separate project, setting up proper inter-project dependencies and letting Gradle default behaviour take care of building all properly. I'd say that what's messy is trying to do anything to prevent re-organizing files on disk even if inter-module dependencies suggest you should extract a common part.