The root cause of the build failure something has a null message which
means there's no information available about why the build failed.
Instead of calling fail when a BuildException occurs, this commit
wraps it in a RuntimeException and rethrows it. This should make the
entire chain of exceptions available when a failure occurs.
The output capture for the deprecation warning only appears to work
when the test is run in isolation. I can't figure out why that's the
case, particularly as we have another test class
(BootRunResourceTests) that uses OutputCapture and works reliably.
I'm cutting my loses and removing the use of OutputCapture and the
assertion that the warnings is logged.
See 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
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, 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
When an application is run as an executable archive with nested jars,
the application's own classes need to be able to load classes from
within the nested jars. This means that the application's classes need
to be loaded by the same class loader as is used for the nested jars.
When an application is launched with java -jar the contents of the
jar are on the class path of the app class loader, which is the
parent of the LaunchedURLClassLoader that is used to load classes
from within the nested jars. If the root of the jar includes the
application's classes, they would be loaded by the app class loader
and, therefore, would not be able to load classes from within the
nested jars.
Previously, this problem was resolved by LaunchedURLClassLoader being
created with a copy of all of the app class laoder's URLs and by
using an unconventional delegation model that caused it to skip its
parent (the app class loader) and jump straight to its root class
loader. This ensured that the LaunchedURLClassLoader would load both
the application's own classes and those from within any nested jars.
Unfortunately, this unusual delegation model has proved to be
problematic. We have seen and worked around some problems with Java
Agents (see gh-4911 and gh-863), but there are others (see gh-4868)
that cannot be made to work with the current delegation model.
This commit reworks LaunchedURLClassLoader to use a conventional
delegate model with the app class loader as its parent. With this
change in place, the application's own classes need to be hidden
from the app class loader via some other means. This is now achieved
by packaging application classes in BOOT-INF/classes (and, for
symmetry, nested jars are now packaged in BOOT-INF/lib). Both the
JarLauncher and the PropertiesLauncher (which supports the executable
jar layout) have been updated to look for classes and nested jars in
these new locations.
Closes gh-4897
Fixes gh-4868
The Maven POM does all the dependency resolutions for the
spring-boot-antlib project. Delegating this task to Ivy, which is
buried deep in the Antrun/Antunit part of the build, makes any kind
of proxy configuration much more complex.
The ivysettings.xml already has the local M2 repository configured,
but because the folder "repository" is missing, the artifacts, already
downloaded by Maven cannot be resolved from this location.
The Spring and Maven Central repositories should be removed from the
ivysettings.xml files in order to force all resolves to be done through
the local M2 repository. The POM of joda-time version 2.8.1 has an
optional dependency to joda-convert 1.2, which lets the Ivy resolve
process fail, because this version of the joda-convert library was
not resolved by any of the Maven POMs. It seems as if Ivy does not
respect the optional scope, defined in the joda-time POM.
Pass proxy settings to the forked process to make the Gradle distribution download work
Create a gradle.properties file for each Gradle integration test and writes the forking
process' proxy settings as systemProp.http(s).Host/Port to the properties file.
This configures the external process with the right proxy settings to let it download
the Gradle distribution via the HTTP proxy server.
Added a hint for Windows users to get the core.autocrlf setting right
When the core.autocrlf setting under Windows is set to false for example
All files are not converted regarding their EOL characters to the
Windows format with CRLF at a line's end. There is a checkstyle
validation that checks that all files have the system's line endings
and in some test-cases the value from the system property "line.ending"
is used to check test output. So without the conversion, those checks
are going to fail, resulting in build errors.
Fixes gh-4367, fixes gh-3816
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
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
Spring Buildmaster
Andy Wilkinson
Phillip Webb
Stephane Nicoll
Johnny Lim
Dave Syer
mrumpf