Previously, ProjectLibraries only considered a configuration's
direct file dependencies. This meant that a transitive file
dependency that should have been pulled in via a project dependency
was not included in the repackaged jar's lib directory.
ProjectLibraries has been updated to walk down the tree of project
dependencies and create libraries for any file dependencies that
are found.
Fixes gh-1368
This commit refines the changes made under 4be688aa. 4be688aa made the
default jar task a special case which broke repackaging of the archive
produced by the default war task.
This commit refines RepackageTask’s logic so that, when it’s enabled,
it will repackage a jar task’s archive if:
- The jar task is equal to RepackageTask.withJarTask
- The name of the jar task is equal to RepackageTask.withJarTask
- RepackageTask.withJarTask is null, the jar task is not referenced
by another RepackageTask’s withJarTask, and the jar task has an
empty classifier
The last of these three is the default case and ensures the, when the
Spring Boot plugin is applied, default jar and war artifacts are
repackaged. The classifier check is required to prevent default source
and javadoc artifacts from being repackaged.
Fixes#1204
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
Update the executable JAR code to automatically unpack any entries
which include an entry comment starting `UNPACK:` to the temp folder.
The existing Maven and Gradle plugins have been updated with new
configuration options and the `spring-boot-tools` project has been
updated to write the appropriate entry comment based on a flag passed
in via the `Library` class.
This support has been added to allow libraries such a JRuby (which
assumes that `jruby-complete.jar` is always accessible as file) to work
with Spring Boot executable jars.
Fixes gh-1070
Add a Library class update the LibraryCallback interface and
implementations to use it. This change is in preparation for
an addition `unpack` flag that will be required to allow the
automatic unpacking of certain nested jars.
See gh-1070
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.
The class Compile was deprecated and will be removed in Gradle 2.0 (it is
already removed in the release canidate).
Instead we should use JavaCompile. Fixes gh-1066.
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
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
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 also convert the SpringBootPlugin to be .groovy to ease defaulting
the encoding to UTF-8. We do not make the file any "more groovy" to leave
this to a distinct commit.
Refactor and rework several areas of the Gradle plugin:
- Refactor package structure into functional areas and configure each
area separately via a new PluginFeatures interface.
- Convert BootRunTask to extend RunTask rather than attempting to
find existing RunTasks.
- Simplify agent integration by no longer needing specific BootRunTask
code.
- Update the repackage task to consider the `mainClassName` property
in addition to `springBoot.mainClass`.
- Automatically set `mainClassName` when calling `run` or `runBoot`
from `springBoot.mainClass` if there is one.
- Ensure that explicitly defined `main` options on JavaExec tasks always
take precedence.
Fixes gh-547, gh-820, gh-886, gh-912
Add a `versionManagement` gradle configuration which can be used to
provide alternative version meta-data. Primarily added so that the
Spring IO platform can provide version overrides without causing a
cyclic build dependency.
Fixes gh-750
Phillip Webb
Andy Wilkinson
Spring Buildmaster
Phillip Webb
Andy Wilkinson
Dave Syer
Rob Winch