Previously, Repackage would attempt to repackage every jar in the
project. This would cause it to incorrectly attempt to repackage source
and javadoc jars.
This commit updates Repackage so that it ignores any jar with a
classifier. Hopefully this is a reasonable approximation for ignoring
'special' jars that should not be repackaged such as sources and
javadoc.
Previously, GrapeEngineInstaller would only install its GrapeEngine
if an engine had not already been installed. As the Grape class stores
the engine in a static field, this meant that the engine would only be
installed once for the lifetime of Grape's classloader. This caused
an ordering issue in SampleIntegrationTests.
The test for the integration sample clears the
disableSpringSnapshotRepos system property to allow M1 of the
integration DSL to be resolved. However, this property is only
examined and honoured in AetherGrapeEngine's constructor. If another
test had run and had already created and installed an
AetherGrapeEngine, the new AetherGrapeEngine that allowed the use of
snapshot repositories would not be installed and the test would fail.
This commit updates GrapeEngineInstaller so that it always installs
its GrapeEngine, overwriting any previously installed engine.
Previously, the Ivy-based Grape engine used a system property,
disableSpringSnapshotRepos, to control whether or not Spring's
snapshot and milestone repositories were used for dependency
resolution. This commit adds the same capability to AetherGrapeEngine.
[#59489826]
Depending on ASM itself can cause problems as it can clash with other
libraries' dependency on it. This commit updates
spring-boot-loader-tools to depend upon spring-core and use its
repackaged copy of ASM instead. Depending on spring-core also brings
with it the advantage of giving access to its various bits of utility
code.
spring-boot-maven-plugin has been updated to remove its ASM
exclusions as they will no longer clash with the version from
spring-boot-loader-tools
(59483608)
@Grab allows a dependency to be declared, but for its transitive
dependencies to be excluded by setting transitive to false. This
commit enhances AetherGrapeEngine to honour this setting by using a
wildcard exclusion on any dependency so declared.
SpringApplication (and the builder) now do not accept default
command line args because the override semantics were wrong -
you need to be able to override them with everything, including
system properties and external properties (per profile).
Also implements new semantics for profiles - you can add
additional profiles in the Java API and they will not be
squashed by command line or system properties entries for
spring.profiles.active.
[Fixes#58989906] [bs-336] DefaultArgs -> DefaultProperties
Use of hasMappingForPattern was commented out during work on the
Aether-based Grape implementation as it was temporarily removed in
Spring 4's snapshots. It's since been reinstated in the snapshots, so
its use should have been reinstated prior to merging Aether work into
master.
Prior to this commit, the Aether-based GrapeEngine was loaded in the
same class loader as the rest of Boot. This led to Aether's and its
dependencies' types polluting the application's class path. Most
notably, this caused problems with logging as the logging framework
could be permaturely initialized.
This commit isolates AetherGrapeEngine, Aether and its dependencies
into a separate class loader. This is done by customizing the
packaging of the CLI's jar file with the internal directory housing
all of the types that will be loaded by the separate class loader.
Previously, @Grab annotations would use Ivy to download the
dependencies with some of Ivy's known limitations being worked around
by GrapeEngineCustomizer.
This commit adds a GrapeEngine implementation that uses Aether,
the dependency resolution 'engine' used by Maven and Grails. To ensure
consistent behaviour with a Maven build, the Aether-powered dependency
resolution uses the dependency management configuration from the
spring-boot-starter-parent pom file.
The Git plugin was primarily being used to provide version information
that Boot's maven plugin can add into the MANIFEST.MF of the uber-jars
that it creates under the Spring-Boot-Commit-Id attribute.
This commit removes the Git plugin from Boot's own projects, but
leaves it in the spring-boot-starter-parent for use by Spring
Boot-based applications.
The attribute in the uber-jars' MANIFEST.MF has been replaced with a
Spring-Boot-Version attribute. The value of this attribute is the
implementation version of Repackager class's package.
Fix RandomAccessJarFile to correctly read certificate information as
jar entries are loaded. This change allows signed nested jars to be
used as JCE providers.
To use PropertiesLauncher instead of JarLauncher in an
executable JAR we have provided tooling support. In Maven
(using the starter parent to default some of the settings):
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<layout>ZIP</layout>
</configuration>
</plugin>
in Gradle:
apply plugin: "spring-boot"
springBoot {
layout = 'ZIP'
}
}
[Fixes#58837492] [bs-330] Add tooling for PropertiesLauncher
PropertiesLauncher can now be used to run an executable jar, and by
default it will pick up nested archives in lib/ (where the Boot
tools puts them). User can provide loader.path (colon-separated)
to change the nested path.
[#58837492] [bs-330] Add tooling for PropertiesLauncher
...otherwise you can see cryptic NoClassDefFound errors
because the application class was loaded from the parent
on the file system, but then it doesn't have access to the
child loaders nested jars.
E.g. with a prefix spring.jpa.hibernate. we want naming-strategy and
namingstrategy to be resolvable. It wasn't working before this change
because the whole property path was being manipulated, where you
actually need to manipulate the prefix and suffix separately.
Phillip Webb
Andreas Kluth
Andy Wilkinson
Dave Syer