Gradle: How to exclude JAR from a WAR?

Question

I have a multi-project Gradle build structure, where child project depends on a JAR, which I don't want to be in WAR file. I tried "exclude" but it does not work.

The main project script:

apply plugin: 'war'
war {
    dependencies {
        runtime (project(':childProject')) {
            exclude group: 'javax.servlet.jsp', module: 'jsp-api'
        }
    }
}

The childProject script:

apply plugin: 'java'
dependencies {
    compile 'javax.servlet.jsp:jsp-api'
}

Solution 1

I'm doing it this way.

war {   
    rootSpec.exclude("**/some-*.jar")
}

Solution 2

From the Gradle documentation

The War plugin adds two dependency configurations: providedCompile and providedRuntime. Those configurations have the same scope as the respective compile and runtime configurations, except that they are not added to the WAR archive.

So, in other words, adding an entry to providedCompile or providedRuntime will cause that dependency to be excluded from the war file.

• use providedCompile if you have source that relies on some classes for compiling
• use providedRuntime if you use it for testing and not compiling.

http://www.gradle.org/docs/current/userguide/war_plugin.html

Example

providedCompile "javax.servlet:servlet-api:2.5"

Solution 3

I realised that providedCompile sometimes introduced dependencies issues for me, e.g. some classes are not found. I then figured out a more flexible solution.

We can just configure required dependencies as 'compile' and then exclude specific jars from the war file by using the following war configuration:

war {
    classpath = classpath.filter { file ->
        println file.name
        (
            !file.name.startsWith('gwt-dev') &&
            !file.name.startsWith('gwt-user') &&
            !file.name.startsWith('guava-gwt') &&
            !file.name.startsWith('gwtbootstrap3') &&
            !file.name.startsWith('gwtbootstrap3-extras') &&
            !file.name.startsWith('servlet-api')
        )
    }
}

So far, I found this is the cleanest solution for me. I hope it helps.

Solution 4

I had the same problem but i found a generic solution based on the one of Jake W.

In your child-project, without the war plugin, you add your own providedCompile and providedRuntime like this:

configurations {
  providedCompile
  providedRuntime.extendsFrom providedCompile
}

plugins.withId('java') {
  configurations {
    compile.extendsFrom providedCompile
    runtime.extendsFrom providedRuntime
  }
}

In the project with your war file you copy this anywhere you want:

configurations.runtime.allDependencies.withType(ProjectDependency) { ProjectDependency dep ->
  Project proj = dep.dependencyProject
  evaluationDependsOn(proj.path)
  Configuration cfg = proj.configurations.findByName('providedRuntime')
  if (cfg != null){
    war {
      classpath -= cfg
    }
  }
}

View more solutions

Comments

[Peter Niederwieser]

I don't think that excludes are supported for project dependencies. (See John's answer for a working solution.) The dependencies block is a top-level element, and should not be nested inside war.

[isobretatel]

Works: apply plugin: 'war' dependencies { runtime (project(':childProject')) { } providedCompile "javax.servlet.jsp:jsp-api" }

[HankCa]

I want to exclude a jar from the war due to file size reasons. SpringBoot (which I'm using) unfortunately moves the jars to WEB-INF/lib-provided for the case of using an embedded server.

[VeenarM]

I liked, this but this to me filtered out all values of that jar - i only wanted to remove duplicates. issues.gradle.org/browse/GRADLE-1454 provided a solution similar that only excludes duplicates

[Jake W]

I guess you will need to write some custom logic in it to remove duplicates. As you can see, we can print all file names

[VeenarM]

Yup, got it done and working as I wished, but yours put me on the right track to solve it, it's an odd case and it's only a problem temporarily until the other artifacts are put into maven and not just dropped into a lib dir.

[GreenGiant]

This didn't work for me, but when I changed the scope to "provided" instead of "providedComile/Runtime", then it worked.

[Dcortez]

It's sad that why have to use this kind of hack to get this done.