When testing an upgrade to Gradle 3.4, we noticed a regression in how war classpaths are handled when using a Copy task to copy from a War task as a with.
In this case, we have a provided configuration that minuses itself from the war task classpath, however as of Gradle 3.4.x, that no longer works in multi-project configurations.
Expected Behavior
The copied files do not include provided libraries:
└── webapp-component
├── build
│ ├── libs
│ │ └── exploded
│ │ ├── META-INF
│ │ │ └── MANIFEST.MF
│ │ └── WEB-INF
│ │ └── lib
│ │ └── shared-component.jar
│ └── tmp
│ └── war
│ └── MANIFEST.MF
Current Behavior
The copied files include the provided libraries:
└── webapp-component
├── build
│ ├── libs
│ │ └── exploded
│ │ ├── META-INF
│ │ │ └── MANIFEST.MF
│ │ └── WEB-INF
│ │ └── lib
│ │ ├── commons-lang3-3.3.2.jar
│ │ └── shared-component.jar
│ └── tmp
│ └── war
│ └── MANIFEST.MF
Context
This breaks our legacy provided plugin that stood in for compileOnly in earlier Gradle releases.
Steps to Reproduce
This reduced project will allow you to reproduce the issue, run the explodedWar task to demonstrate the behavior:
https://github.com/DanielThomas/provided-reduced
Your Environment
Gradle 3.4.1
When testing an upgrade to Gradle 3.4, we noticed a regression in how war classpaths are handled when using a Copy task to copy from a War task as a
with.In this case, we have a
providedconfiguration thatminusesitself from the war task classpath, however as of Gradle 3.4.x, that no longer works in multi-project configurations.Expected Behavior
The copied files do not include provided libraries:
Current Behavior
The copied files include the provided libraries:
Context
This breaks our legacy
providedplugin that stood in forcompileOnlyin earlier Gradle releases.Steps to Reproduce
This reduced project will allow you to reproduce the issue, run the
explodedWartask to demonstrate the behavior:https://github.com/DanielThomas/provided-reduced
Your Environment
Gradle 3.4.1