Previously, the CLI’s dependency management used proprietary Properties
file-based metadata to configure its dependency management. Since
spring-boot-gradle-plugin’s move to using the separate dependency
management plugin the CLI was the only user of this format.
This commit updates the CLI to use Maven boms to configure its
dependency management. By default it uses the spring-boot-dependencies
bom. This configuration can be augmented and overridden using the new
@DependencyManagementBom annotation which replaces @GrabMetadata.
Closes gh-2688
Closes gh-2439
This reverts commit b1c0a7cda4.
The plugin publishing process has moved to a new plugin-based approach
that brings with it some significant limitations:
- There's no staging to allow the promotion of good release builds
- There's no easy way to upload an existing artifact
- There's no control over the published pom.
The risk brought by these limitations, particularly the first, are
too great so we will no be publishing the Boot plugin to the Portal
until they're resolved.
Changing the plugin's ID was a breaking change that would require
users to do some work when they upgrade to Boot 1.3. The ID of the
plugin was changed purely so that it met the Portal's requirements.
Given that the plugin will not be published to the Portal for the
foreseaable future there's no need for us to inflict a breaking change
on people when there will be no benefit.
See gh-1567
Update the Maven and Gradle plugin to generate fully executable jar
files on Unix like machines. A launcher bash script is added to the
front of the jar file which handles execution.
The default execution script will either launch the application or
handle init.d service operations (start/stop/restart) depending on if
the application is executed directly, or via a symlink to init.d.
See gh-1117
Gradle’s plugin portal requires each plugin’s ID to be in a namespace.
Our existing ID, spring-boot, does not meet this requirement. This
commit changes the plugin’s ID to org.springframework.boot.spring-boot.
Note that, as is recommended [1], the plugin’s ID does not include
“gradle”.
See gh-1567
[1] http://plugins.gradle.org/submit
Following the move to using the separate dependency management plugin
this test is no longer valid. It should have been removed as part of
2c3c62d7
See gh-2133
This commit replaces Spring Boot's basic dependency management support
with separate dependency management plugin. This has a number of
benefits including:
1. A Maven bom can be used rather than a custom properties file
2. Dependency management is applied transitively rather than only to
direct dependencies
3. Exclusions are applied as they would be in Maven
4. Gradle-generated poms are automatically configured with the
appropriate dependency management
Closes gh-2133
The Maven plugin allows spring-boot:run to be configured so that
resources are loaded from their output location rather than from
src/main/resources. This commit adds an equivalent configuration
option to the Gradle plugin. To disable source resources from being
added to the classpath in place of those in the output location
the configure the bootRun tasks like this:
bootRun {
addResources = false
}
Closes gh-2431
By default, when building a project's jar its runtime dependencies
are not taken into account as they are not needed to successfully
compile the code that will be packaged in the jar. A side-effect of
this was that, if a project that was being repackaged had a runtime
dependency on another project, then the repackaged jar would not
include the jar of the project on which it has the runtime dependency
as the jar had not been built.
This commit updates Boot's repackage task to have a dependency on the
jar task of any project dependencies in the runtime configuration
thereby ensuring that those dependencies' jars will have been built
before the repackaging occurs.
Fixes gh-2344
Add a 'module' layout for the repackager which includes all 'compile'
and 'runtime' scope dependencies and does not require a main class.
Fixes gh-1941
Previously, the Gradle plugin’s ProjectLibraries produced a new library
for every file dependency, even if the dependencies where on the same
file. This would lead to a repackaging failure due to multiple
libraries having the same name.
This commit updates ProjectLibraries to treat file dependencies on the
same file as a single library, thereby resolving the name clash.
Fixes gh-1646
The fix for gh-1475 introduced the use of an artifact's group to
discriminate between two libraries with the same name (artifact id)
and version. However, in the case of Gradle, a group name was not
provided for libraries that have been resolved from a repository.
This commit updates ResolvedArtifactLibrary to use the group obtained
from the underlying ResolvedArtifact as its discriminator.
Fixes gh-1543
The applicationDefaultJvmArgs property was added in Gradle 1.7. This
commit updates RunPluginFeatures to access the property defensively
so that the plugin can be used with Gradle 1.6.
Fixes gh-1511
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, ProjectLibraries only considered a configuration's
direct file dependencies. This meant that a transitive file
dependency that should have been pulled in via a project dependency
was not included in the repackaged jar's lib directory.
ProjectLibraries has been updated to walk down the tree of project
dependencies and create libraries for any file dependencies that
are found.
Fixes gh-1368
This commit refines the changes made under 4be688aa. 4be688aa made the
default jar task a special case which broke repackaging of the archive
produced by the default war task.
This commit refines RepackageTask’s logic so that, when it’s enabled,
it will repackage a jar task’s archive if:
- The jar task is equal to RepackageTask.withJarTask
- The name of the jar task is equal to RepackageTask.withJarTask
- RepackageTask.withJarTask is null, the jar task is not referenced
by another RepackageTask’s withJarTask, and the jar task has an
empty classifier
The last of these three is the default case and ensures the, when the
Spring Boot plugin is applied, default jar and war artifacts are
repackaged. The classifier check is required to prevent default source
and javadoc artifacts from being repackaged.
Fixes#1204
The logic that determined whether or not the repackaging action should
be applied to a particular jar task was broken and caused problems
when a custom RepackageTask was used in a project's build.
This commit updates the logic so that repackaging will be applied:
- To the default jar task if RepackageTask.withJarTask is null
- To a jar task if it is equal to RepackageTask.withJarTask
- To a jar task if its name is equal to RepackageTask.withJarTask
Repackaging is not applied if:
- RepackageTask.enabled is false
Numerous integration tests have been added to verify the repackaging
behaviour.
Fixes#1204
The new ResolvedArtifact-based minus implementation was checking the
wrong Set when deciding whether or not a ResolvedArtifact should
be included in the result. This was leading to provided dependencies,
that should have only been packaging in WEB-INF/lib-provided also
being packaged in WEB-INF/lib.
The WarPackaging tests have been updated. In addition to checking that
WEB-INF/lib-provided does not contain anything that’s unexpected, they
also verify the contents of WEB-INF/lib
Fixes#1187
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 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
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
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.
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
Add a `versionManagement` gradle configuration which can be used to
provide alternative version meta-data. Primarily added so that the
Spring IO platform can provide version overrides without causing a
cyclic build dependency.
Fixes gh-750
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
Prior to this commit, a dependency on a local file was not being
packaged by the Gradle plugin. This was a regression from the behaviour
in 0.5.0.M6 caused by the move to using a ResolvedConfiguration and
ResolvedArtifacts (4f677bec) to gain access to an artifact's type so
that non-jar artefacts could be filtered out. Since then, the approach
to filtering has been changed (38585bf3) and access to an artifact's
type is no longer needed.
This commit updates ProjectLibraries to restore its use of a
FileCollection rather than a ResolvedConfiguration when getting hold of
the files in a configuration. This means that the resulting jar will
now include dependencies that aren't resolved, such as those that are
provided as local files. The filtering that is applied to the files
is unaffected by this change and only files that are zip files will be
included.
Fixes#672
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
Remove README files that have been since been migrated to the reference
documentation. Also updated remaining markdown files to asciidoctor to
save having a mix of different formats.
Fixed gh-503
We had been making a special case for logback.xml anyway, so
extending that to simply deleting recursively all of
src/main/resources (or equivalent) from target/classes (or
equivalent) seems like it's perfectly justifiable.
Fixes gh-451
Requires Loaded 1.1.5 (or better).
For Maven you can just add springloaded to the dependencies of the
spring-boot plugin (and also set MAVEN_OPTS=-noverify).
For Gradle add springloaded to the build dependencies (-noverify
can be added by the plugin).
In both cases there is also support for adding an arbitrary java agent
via configuration. Samples are provided in
spring-boot-sample-[simple,web-ui].
The ApplicationPlugin is only added if there is no JavaExec task
already present, and additionally it computes its own man class if
none is provided. So "gradle run" and "gradle bootRun" look
superficially similar, but "bootRun" has extra options, including
the agent and Loaded support.
Fixes gh-251, gh-183
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
Spring Buildmaster
Andy Wilkinson
Sylvère Richard
Phillip Webb
Stephane Nicoll
Stephane Nicoll
Phillip Webb
Andy Wilkinson
Dave Syer
Rob Winch
Janne Valkealahti
Adam Brodziak