The logic that determined whether or not the repackaging action should
be applied to a particular jar task was broken and caused problems
when a custom RepackageTask was used in a project's build.
This commit updates the logic so that repackaging will be applied:
- To the default jar task if RepackageTask.withJarTask is null
- To a jar task if it is equal to RepackageTask.withJarTask
- To a jar task if its name is equal to RepackageTask.withJarTask
Repackaging is not applied if:
- RepackageTask.enabled is false
Numerous integration tests have been added to verify the repackaging
behaviour.
Fixes#1204
The new ResolvedArtifact-based minus implementation was checking the
wrong Set when deciding whether or not a ResolvedArtifact should
be included in the result. This was leading to provided dependencies,
that should have only been packaging in WEB-INF/lib-provided also
being packaged in WEB-INF/lib.
The WarPackaging tests have been updated. In addition to checking that
WEB-INF/lib-provided does not contain anything that’s unexpected, they
also verify the contents of WEB-INF/lib
Fixes#1187
The default behaviour doesn't change with this commit, but now
the user has the option to specify a 'classifier' property
either in springBoot { classifier = 'exec' } (i.e. globally
for all repackage tasks) or in each repackage task, e.g.
bootRepackage { classifier = 'exec' }. In that case the original
archive is not overwritten but copied into <file>-<classifier>.jar
(or .war etc.) and then enhanced.
Fixes gh-1113, fixes gh-141 also I believe.
I'm sure someone can do a better job of this, but here's a proposal
that works. It uses our FindMainTask to set the relevant properties
if theu are missing in the application plugin.
Fixes gh-1105
Simplify the exclusion logic used in Gradle by implementing implicit
exclusions rather than trying to detect transitive excludes.
This commit reverts much of the code originally included to fix gh-1047
which adds far too much complexity to the build and still doesn't solve
the underlying issue.
Fixes gh-1103
The test is a bit crap at the minute (no assertion), but the build
is successful and you can see from the log that the correct main
is used
Fixes gh-1099
There was a problem with the Gradle plugin packaging application
dependencies in WEB-INF/lib-provided when only the servlet container
and its dependencies should be packaged there. See #1064 for details.
This commit adds two tests, one for Tomcat and one for Jetty, to
verify that only the expected entries appear in WEB-INF/lib-provided.
Closes#1071
Previously, the versionManagement configuration was resolved as part of
the Boot Gradle plugin being applied. This meant that no dependencies
could be added to it and attempting to do so would result in a failure:
“You can't change a configuration which is not in unresolved state”.
This commit updates ApplyExcludeRules to wrap its processing in a
before resolve action. This defers the resolution of the
versionManagement configuration until one of the project’s other
configurations is being resolved. Fixes#1077
In addition to the above, the transitive exclusions that the Gradle
plugin provides were being lost if custom version management provided
a version for the same dependency. This commit updates
AbstractDependencies to preserve the exclusions from an existing
dependency declaration while using the version from the newer
dependency. This ensures that the exclusions remain while allowing
versions to be overridden. Fixes#1079
Update all starter POMs to remove commons-logging dependencies that are
not longer required when using the Spring Boot Gradle plugin.
Mainly reverts code from 196f92bd42
See gh-1047
Refactor dependency-tools to restore API compatibility with Spring
Boot 1.0. This should reduce reflection hacks that tools such as Gretty
would otherwise have to make.
See gh-1035
We've had problems with the starters when used with Gradle. They have
been pulling in commons-logging (#987) and the wrong version of Spring
(#1028) due to Gradle's different exclusion and dependency resolution
semantics.
This commit adds some integration tests that use Gradle's tooling API
to take each starter in turn and build a Gradle project that depends
upon it. The build looks at the transitive dependencies and checks
that neither commons-logging nor any Spring modules with the wrong
version are present.
Closes#1036
Phillip Webb
Andy Wilkinson
Dave Syer
Phillip Webb
Dave Syer