Hello Hans,

I opened the thread http://www.nabble.com/War-Plugin-problems-td18232294.html and you opened an issue here so I thought I'd continue the documentation in the issue itself.

Declaring the scope of the dependencies is very important not only when packaging war files but also for deploying dependencies as separate files. In a previous thread message I have mentioned the notion of the "<scope>provided</provided>" declaration in Maven. I had a short look at the Ivy documentation and found the notions of "Configurations" that can be used to fulfill a similar purpose as maven scopes. Now if I define my war build.gradle file as following:

dependencies {
compile project(':csl:jars:foundation'), project(':csl:jars:vincommon')
compile "javax.servlet:servlet-api:2.4"
compile "commons-lang:commons-lang:2.1"
}

The war plugin member variable libConfiguration is set to the 'runtime' configuration and since the 'runtime' configuration extends the 'compile' configuration all java plugin 'compile' dependencies are implicitly resolved as 'runtime' dependencies. The War .groovy call 'dependencyManager.resolve(libConfiguration)' will automatically add them all to the /WEB-INF/lib folder.

As an experiment I added a 'provided' configuration to the project dependencies:

dependencies {
addConfiguration( new Configuration( 'provided', Configuration.Visibility.PUBLIC,
'Do not include in runtime configuration', (String[])[], true, null ))
addConf2Tasks( 'provided', (String[])[ 'compile' ])
provided project(':csl:jars:foundation'), project(':csl:jars:vincommon')
provided "javax.servlet:servlet-api:2.4"
compile "commons-lang:commons-lang:2.1"
}

Now however the compile 'task' will only pickup dependencies in the scope of the 'provided' configuration and not 'compile'. It seems that the DefaultDependencyManager mapping of tasks to configurations is one to one.

I think this could be solved if the DefaultDependencyManager member variable task2Conf would store a map of arrays (i.e. [ 'compile' : [ 'compile', 'provided' ], 'war' : [ 'runtime' ]]). This way the 'compile' task could pick up both the 'compile' and 'provided' configurations but the 'war' task would only pickup the 'runtime' configuration which extends 'compile'.

It is kind of funny. We have created infrastructure code to enable this but at the end of the day we don't actually need it for resolving this issue. The war plugin introduces tow new configurations provided and providedCompile. They are extended by compile and provided. The war plugin adds the delta between runtime and providedRuntime to the libs of the war. I think this is the most seamless solution for the problem. But you can now also assign multiple configurations to a task. And you can assign multiple configuration to be used for the libs folder of a war.