Previously, the Gradle plugin’s ProjectLibraries produced a new library
for every file dependency, even if the dependencies where on the same
file. This would lead to a repackaging failure due to multiple
libraries having the same name.
This commit updates ProjectLibraries to treat file dependencies on the
same file as a single library, thereby resolving the name clash.
Fixes gh-1646
The fix for gh-1475 introduced the use of an artifact's group to
discriminate between two libraries with the same name (artifact id)
and version. However, in the case of Gradle, a group name was not
provided for libraries that have been resolved from a repository.
This commit updates ResolvedArtifactLibrary to use the group obtained
from the underlying ResolvedArtifact as its discriminator.
Fixes gh-1543
The applicationDefaultJvmArgs property was added in Gradle 1.7. This
commit updates RunPluginFeatures to access the property defensively
so that the plugin can be used with Gradle 1.6.
Fixes gh-1511
Prior to this commit, the repackage goal silently ignored the case of
two libraries having the same name and version but a different group.
As a result, the second library was overwriting the first one in the
repackaged jar.
This commit adds support for custom Library names and updates the
Maven and Gradle plugins so that the name includes the group ID
when there would otherwise be a duplicate.
Fixes gh-1475
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
Spring Buildmaster
Andy Wilkinson
Phillip Webb
Stephane Nicoll
Phillip Webb
Andy Wilkinson
Dave Syer