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, Repackager would repackage a jar file as many times as
it was asked to do so. This lead to problems if a user made a mistake
when using Maven that led to the package phase being driven twice,
for example by running "mvn clean install package".
This commit updates Repackager so that a repackage call becomes a
no-op if the source jar's manifest already contains the
Spring-Boot-Version attribute which is added by repackaging.
Fixes#1251
Before this change a property whose key was in a non-enumerable property source would
not resolve placeholders, leading to ${style} values in @ConfigurationProperties beans
even if the placeholders ere resolvable.
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 main difference for now is the removal of the --nohup
(slightly hacky) option in TestCommand. Now a TestCommand
can signal to its caller that it wants to be hung up.
Fixes gh-975
Restore the dependency on commons-logging (transitively via spring-core)
for spring-boot. This means that we are not tied directly to SLF4J, but
it is still an option that can be used via `jcl-over-slf4j`.
The `spring-boot-starter-parent` continues to replace `commons-logging`
with `jcl-over-slf4j`.
Fixes gh-981
Unify the versions used in integration tests launched by the
maven-invoker-plugin. Allows for already cached local copies to be
used, hopefully speeding up the build.
This (empirically) fixes gh-726 using a new utility
(LogbackInitializer) in the loader tools. If anyone has enough
Gradle fu to understand where to put it (after the classpath is established
but before compilation) we could do the same thing in the Gradle plugin
(and that would fix gh-724).
This commit harmonizes the dependency management of internal modules
so that versions can be omitted everywhere. Update the maven coordinates
to provide the full groupId for consistency
There were several problems to fix. 1) a bug in the
JDK (1.7 up to 7_60):
https://bugs.openjdk.java.net/browse/JDK-8023130
which we can work around by detecting buggy VMs and not trying
to use inheritIO. 2) File<->URL conversion is platform dependent
and we shouldn't make any assumptions. The problem in this case
was that file URLs contain a ":" so they can 't be added to a
path in UNIX, but on Windows you need the absolute path with the
colon. Solution: use Files on the classpath for spring-boot:run.
Hopefully also fixes gh-767
Phillip Webb
Stephane Nicoll
Spring Buildmaster
Phillip Webb
Andy Wilkinson
Dave Syer
Stephane Nicoll
Andy Wilkinson