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.