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.
Andy Wilkinson
Spring Buildmaster
Phillip Webb
Stephane Nicoll
Stephane Nicoll
Phillip Webb
Andy Wilkinson
Dave Syer