Previously, the Gradle plugin would package all of a project's
dependencies in the jar's lib directory, irrespective of each
dependency's type. This led to non-jar artifacts being packaged in
the lib directory where only jar dependencies are expected. See #334
for an example failure.
This commit updates the Gradle plugin such that it only packages
dependencies of type jar, ejb, ejb-client, test-jar, or bundle. This
brings the Gradle plugin into line with the Maven plugin.
Fixes#334.
Add `mainClass` property option to the Repackage task. If the property
is defined within a task, it works in the same way as if it defined
within the springBoot{} 'ext' properties section.
Option is valid only for that specific task where it is defined, and
will override option defined in springBoot{} ext properties.
Fixes gh-283
Update `GroovyCompiler` and `AetherGrapeEngineFactory` to use the
recently added `spring-boot-dependency-tools` in favor of loading
dependency information from a generated properties file.
Add a gradle `ResolutionStrategy` that resolves missing version numbers
using the `spring-boot-dependencies` POM.
This commit also introduces a new `spring-boot-dependency-tools` module
that provides programmatic access to the `dependencyManagement` section
of the dependencies POM.
Fixed gh-262
Update the maven and gradle plugins to fail the build if a single
unique main class cannot be found. Additionally plugins will warn
if the search is taking too long.
Fixes gh-210
Usage:
$ gradle bootRun
...
Edit files in src/main/resources and see the changes live in a web app
(e.g. static resources in /static).
The old functionality of bootRun has been replaced (since it didn't add
a lot of value and also didn't expose any JMV argument setters of anything).
This new feature set is backed by any existing "run" task configuration.
In addition autodetects a main class if there is one in the project
sources, so no need for mainClassName = '...' in build.gradle.
Applies the 'application' plugin (so no need to declare that either).
Fixes gh-225
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.
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.
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
Phillip Webb
Andy Wilkinson
Janne Valkealahti
Adam Brodziak
Dave Syer
dave noel
Phil Webb
Phillip Webb