Tweak 'fat jar' handling to generally improve performance:
- Allow JarURLConnection to throw a static FileNotFoundException when
loading classes. This exception is thrown many times when attempting
to load a class and is silently swallowed so there is no point in
providing the entry name.
- Expose JarFile.getJarEntryData(AsciiBytes) and store AsciiBytes in
the JarURLConnection. Previously AsciiBytes were created, discarded
then created again.
- Use EMPTY_JAR_URL for the JarURLConnection super constructor. The URL
is never actually used so we can improve performance by using a
constant.
- Extract JarEntryName for possible caching. The jar entry name
extracted from the URL is now contained in an inner JarEntryName
class. This could be cached if necessary (although currently it is
not because no perceivable performance benefit was observed)
Fixes gh-1119
Update JarFile to reuse the previously parsed entries when creating
filtered jars. This saves needing to re-scan the underlying file to
recreate a subset of entries.
See gh-1119
Drop JarEntryFilter arguments from the JarFile constructor and the
getNestedJarFile methods. Filtered JarFiles can still be obtained by
using the getFilteredJarFile() method.
This helps simplify the code a little and will make it easier to add
caching.
See gh-1119
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
Update `spring-boot-loader` ZIP processing code to support prefixed
bytes within the fat jar. This technique allows a bash script to be
embedded at the start of the JAR whilst still allowing `java -jar`
execution.
Fixes gh-1073
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
Update spring-boot-dependency-tools to support transitive excludes.
Transitive excludes are useful with Gradle which considers each
dependency independently (see GRADLE-3061).
Transitive excludes are supported by parsing the dependency-tree file
from spring-boot-versions.
See gh-1047
Refactor dependency-tools to restore API compatibility with Spring
Boot 1.0. This should reduce reflection hacks that tools such as Gretty
would otherwise have to make.
See gh-1035
We also convert the SpringBootPlugin to be .groovy to ease defaulting
the encoding to UTF-8. We do not make the file any "more groovy" to leave
this to a distinct commit.
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.
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.
Refactor and rework several areas of the Gradle plugin:
- Refactor package structure into functional areas and configure each
area separately via a new PluginFeatures interface.
- Convert BootRunTask to extend RunTask rather than attempting to
find existing RunTasks.
- Simplify agent integration by no longer needing specific BootRunTask
code.
- Update the repackage task to consider the `mainClassName` property
in addition to `springBoot.mainClass`.
- Automatically set `mainClassName` when calling `run` or `runBoot`
from `springBoot.mainClass` if there is one.
- Ensure that explicitly defined `main` options on JavaExec tasks always
take precedence.
Fixes gh-547, gh-820, gh-886, gh-912
ExecutableArchiveLauncher creates a ClassLoader that is used by the
Launcher to load an application’s classes. During the creation of this
ClassLoader URLs from another ClassLoader are copied over. This was
resulting in Java agents that are added to the system class loader
via the -javaagent launch option being available on both the system
class loader and the created class loader. Java agents are intended to
always be loaded by the system class loader. Making them available on
another class loader breaks this model.
This commit updates ExecutableArchiveLauncher so that it skips the URLs
of any Java agents (found by examining the JVM’s input arguments) when
copying URLs over to the new classloader, thereby ensuring that Java
agents are only ever loaded by the system class loader.
Fixes#863
Add a new maven project containing a versions.properties file and
an effective POM. Rework existing projects to use the versions
artifacts.
Partially reverts 307fbba9e4
Fixes gh-913
Previously spring-boot-dependency-tools used spring-boot-tools as its
parent. This meant that it inherited spring-boot-parents' dependency
management that we did not want to expose to applications. The
solution to this was to generate the effective pom and then filter
out any thing that did not appear in spring-boot-dependencies' pom.
This filtering had to unwanted side-effect of breaking bom imports:
the effective pom would contain the dependency management from the
imported bom, but this would be filtered out as the entries didn't
appear in spring-boot-dependencies' pom.
This commit updates spring-boot-dependency-tools to use
spring-boot-dependencies as its parent. This means that its effective
pom contains the desired dependency management and nothing more,
allowing the filtering logic to be removed.
The use of Spring Security's bom has been reinstated as it will now
work as intended and versions for its modules will be available in the
CLI and via the Gradle plugin.
Closes#825Fixes#838
