Allow support for custom Lyout implementations with both the Maven
and Gradle plugin. Implementations of `LayoutFactory` can now be
specified to allow customization of the layout. In addition a
layout may now implement `CustomLoaderLayout` if it wishes to
write custom loader classes.
See gh-7263
To be compatible with Gradle's plugin portal, plugins must have an
ID that uses a reverse domain name. This means that spring-boot is
not compatible.
This commit introduces a new ID, org.springframework.boot, and
deprecates the old ID.
Closes gh-6997
To be compatible with Gradle's plugin portal, plugins must have an
ID that uses a reverse domain name. This means that spring-boot is
not compatible.
This commit introduces a new ID, org.springframework.boot, and
deprecates the old ID.
Closes gh-6997
Previously, Maven repositories definition was specified in a profile that
is active by default. It means that as soon as any profile is enabled by
the user, said profile is no longer enabled. This has the nasty
consequences of having copy/paste in several places to make sure our own
profiles still have the proper repositories definition.
This commit creates a single "repositories" profile that is always active
unless a given property is explicitely specified. This allows to remove
the duplication and make things more consistent.
Some Gradle-specific repositories were also hard-coded in two modules
without any profile at all, meaning they were polluting the build of
anybody using it. While the impacted modules are gradle specific, that
repository has been shared in the new "repositories" profile as well.
Closes gh-6031
This commit improves the `InfoContributor` infrastructure as follows:
* `InfoEndpoint` no longer breaks its public API and returns a Map as
before
* `Info` is now immutable
* All properties of the build are now displayed. Since we control the
generation of that file, there is no longer a mode to restrict what's
shown
* Build info is now generated in `META-INF/build-info.properties` by
default
Closes gh-5734
Previously, the Gradle plugin would include all of the dependencies
from both the compile and runtime configurations in the repackaged
jar. In the unlikely event that the compile and runtime configurations
contained different versions of the same dependency, this would lead
to both versions of the dependency being packaged in the jar file.
The runtime configuration extends the compile configuration so, in
normal circumstances, it will contain a superset of the compile
configuration's dependencies. In the situation described above where
the two configurations contain different versions of the same
dependency the runtime configuration will only contain whichever
version of the two dependencies has "won". By default, this will
be the dependency with the higher version.
This commit updates the Gradle plugin to only include the runtime
configuration's resolved dependencies during repackaging. As explained
above, the runtime configuration extends the compile configuration so
any compile dependencies will still be included, with the added
benefit that duplicate versions of the same dependency will have been
resolved to a single, preferred version.
Closes gh-5749
Previously, the default BuildInfo task created by the DSL was called
buildInfo. Due to Gradle's lack of namespacing for tasks, this meant
there was a slight risk that it could clash with another task. It
also didn't following the naming used by Boot's run task which is
named bootRun.
This commit renames the default BuildInfo task to bootBuildInfo to
match bootRun and to hopefully avoid clashes with tasks from other
plugins.
Closes gh-5518
Previously, FindMainClassTask would look for a property named main
on any class named run. This was based on the assumption that the
run task would be a JavaExec task (typically provided by the
application plugin). If the run task was not a JavaExec task (more
accurately, if it did not have a main property) this would result in
a build failure due to trying to read a non-existent property.
This commit updates FindMainClassTask to only use the main property
of the run task if the task is a JavaExec task. This guarantees that
the property will exist on the task, and unlike using any property
named main on a task named run, also guarantee that its value will
refer to a Java class with a main method.
Closes gh-5501
The commit adds a new BuildInfo task that can be used to generate
a build.properties file, intended for inclusion in the Actuator's
info endpoint.
A default instance of the task can be configure using the plugin's
DSL:
springBoot {
buildInfo()
}
Additional properties can also be configured using the DSL:
springBoot {
buildInfo {
additionalProperties = [
'foo': 'bar'
]
}
}
When configured via the DSL, the Java plugin's classes task is
configured to depend on the build info task. Alternatively, if more
control is required, the task can be declared and configured manually:
task buildInfo(type: org.springframework.boot.gradle.buildinfo.BuildInfo) {
additionalProperties = [
'foo': 'bar'
]
}
classes {
dependsOn buildInfo
}
See gh-2559
Flip the default value of `addResources` for both the Maven and Gradle
plugins. This effectively turns off static resources reloading and, more
importantly, the pruning of duplicate resources from the target
directory.
As devetools is our mainstram solution for such feature, the documantion
has been updated to reflect that.
Closes gh-4227
Add an `excludeDevtools` property to both the Maven and Gradle plugin
that removes `org.springframework.boot:spring-boot-devtools` (if
necessary) when repackaging the application.
Closes gh-3171
Gradle 2.0, and only 2.0, requires a Plugin implementation to be
public. The changes made in gh-4113 (9c14ed3) made the class
package-private.
Closes gh-4139
Replace existing Groovy code with Java since the Groovy Eclipse tooling
currently forces the use of an old jdt plugin which has formatter bugs.
Fixes gh-4113
8673250 updated the plugin so that the application plugin is no longer
applied by default. This exposed three problems:
1. bootRepackage may run before findMainClass has run, leaving it with
an unknown main class.
2. findMainClass may run before the classes have been built, making it
unable to find the main class by examining the class files
3. The project's mainClassName property was still being used as a
convention for the bootRun task's main property. If the application
plugin has not be applied, then this property does not exist.
The first problem has been addressed by configuring bootRepackage to
depend on findMainClass.
The second problem has been addressed by configuring the main source
set's output as an input of findMainClass, and configuring findMainClass
to depend on the tasks that build the output.
The third problem has been addressed by only using the mainClassName
property if it exists and its value is not null. We then fallback to
using the mainClassName property on the project's extra properties in
the same way.
See gh-2679
Previously, the Spring Boot Gradle plugin would always apply the
application plugin to a project. It then piggy-backed on the application
plugin’s mainClassName and applicationDefaultJvmArgs properties for the
configuration of the bootRun task.
This commit updates the Spring Boot Gradle plugin so that it no longer
applies the application plugin. If the user applies the application
plugin then its configuration will be used, but it’s a no longer
requirement.
Users who do not need the application plugin, but who were using the
mainClassName or applicationDefaultJvmArgs properties will need to
change their builds as a result of this change as those properties will
no longer exist. As before, the mainClassName can be configured on the
springBoot extension:
springBoot {
mainClassName 'com.example.YourApplication'
}
The applicationDefaultJvmArgs property can be used, but it must now be
declared with the project's ext block. For example:
ext {
applicationDefaultJvmArgs = [ '-Dcom.example.property=true' ]
}
Closes gh-2679
Spring Buildmaster
Eddú Meléndez
Phillip Webb
Andy Wilkinson
Dave Syer
Stephane Nicoll
Johnny Lim
Martin Lippert