Jetty JARs get in both lib and lib-provided

[hban]

When using Gradle to package application into a WAR, Jetty JARs end up in both lib and lib-provided folders. Those in lib folder will prevent application from being deployed in servlet container (for example, Tomcat).

This issue is present in versions 1.1.2 and 1.1.3. When using Spring Boot version 1.1.1 the resulting WAR file is correct (Jetty JARs are only in lib-provided folder).

build.gradle file to reproduce this problem:

buildscript {
  repositories { mavenCentral() }
  dependencies { classpath 'org.springframework.boot:spring-boot-gradle-plugin:1.1.3.RELEASE' }
}

apply plugin: 'java'
apply plugin: 'spring-boot'
apply plugin: 'war'

sourceCompatibility = 1.7

repositories { mavenCentral() }

configurations.compile {
  exclude group: 'commons-logging'
  exclude module: 'spring-boot-starter-tomcat'
}

dependencies {
  compile 'org.springframework.boot:spring-boot-starter-web'
  providedCompile 'org.eclipse.jetty:jetty-webapp:9.2.1.v20140609'
  providedCompile 'org.eclipse.jetty.websocket:websocket-server:9.2.1.v20140609'
}

task wrapper(type: Wrapper) {
  gradleVersion = '1.12'
}

[dsyer]

Don't you need to set the 'providedConfiguration' in springBoot {}?

springBoot {
  providedConfiguration = 'providedCompile'
}

(from memory).

[hban]

It doesn't help. I also tried moving Jetty from providedCompile to providedRuntime (which is default value for providedConfiguration) and JARs still get placed in both lib and lib-provided.

[wilkinsona]

I've updated WarPackagingTests locally to check that entries expected in WEB-INF/lib-provided don't also appear in WEB-INF/lib. It reproduces the problem using both the Tomcat and Jetty starters.

I think the changes made in f30b962 are the source of the problem. I've yet to figure out why that change required a custom implementation of minus. @philwebb?

[philwebb]

From memory, the custom implementation of minus was needed because the doWithLibraries method was changed to work with ResolvedArtifacts rather than Files. That was needed because I wanted the configuration to specify things in terms of artifact/group rather than file (i.e. unpack org.jruby:jruby).