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
Change the initial fix for OSX Java 1.6 compatibility by removing the
need for a direct `tools.jar` dependency.
It appears that `system` dependencies are always pulled in when
used in a Maven plugin. This makes the the dependency on `tools.jar`
particularly brittle since we need to make assumptions about where
the jar is located.
Since the tools jar is *only* needed for Spring Loaded support, the
plugin has now been updated to locate the jar programmatically and
call it via reflection. This should reduce the risk of problems when
using the plugin and at the very least isolate them to Spring Loaded
support.
(See original commit b8c4720)
Fixes gh-497
When repackaging an archive, the files in the resulting lib directory
must be zip files. If they're not zip files, the resulting archive
may fail to run (#324).
The previous approach was to consider an artifact's type when deciding
whether or not it should be packaged. The type is a string and, while
there are a number of well-known values, it can essentially be anything.
This caused a problem with an artifact incorrectly being identified as
being unsuitable for inclusion (#489).
This commit changes the approach. Rather than looking at an artifact's
type, it looks at the first four bytes of the archive's file. Only if
these header bytes matche that of a zip file is the artifact included.
This is a better match for the requirement that all files in lib be zip
files.
Fixes#489
Currently Spring Boot fails in Java 1.6 on Mac OS X due to the
"tools.jar" being integrated into classes.jar in the Apple version of
Java 6.
Apple fixed this with Java 7, but we should still support Java 6. We had
to roll back to maven-plugin-plugin 3.1 to make this work with Java 6
and 7.
All tests pass with Java 6 and Java 7.
Dave Syer
Stephane Nicoll
Spring Buildmaster
Phillip Webb
Andy Wilkinson
Trevor Menagh