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.
Previously, in the DevTools integration tests, portions of a File's
path were used to create the name of a jar entry. On Windows this
resulted in the entry containing \ characters. As a result the
directory structure was incorrect and the classes could not be loaded
from the jar.
This commit ensures that any \ characters are replaced with /
characters.
See gh-7782
Update `JettyEmbeddedServletContainerFactory` to support Jetty 9.4
directly and Jetty 9.3 via reflection. The primary difference between
Jetty 9.3 and 9.4 are the session management classes. Websocket suppport
has also been updates, but this is handled transparently by the
Spring Framework support.
Fixes gh-7599
Previously, we just waited for the file to exist before trying to read
the port from it. This left a window where the file existed but its
contents had not be written which could result in a
NumberFormatException.
This commit now waits for the file to have a length that is greater
than zero.
See gh-7379
Previously, remote DevTools only correctly supported modifying
existing classes. New classes that were added would be missed, and
deleted classes could cause a failure as they would be found by
component scanning but hidden by RestartClassLoader.
This commit introduces a DevTools-specific ResourcePatternResolver
that is installed as the application context's resource loader. This
custom resolver is aware of the files that have been added and
deleted and modifies the result returned from getResource and
getResources accordingly.
New intergration tests have been introduced to verify DevTools'
behaviour. The tests cover four scenarios:
- Adding a new controller
- Removing an existing controller
- Adding a request mapping to a controller
- Removing a request mapping from a controller
These four scenarios are tested with:
- DevTools updating a local application
- DevTools updating a remote application packaged in a jar file
- DevTools updating a remote application that's been exploded
Closes gh-7379
Previously, a relative PID folder was not handled correctly when
running stop, status, or force_reload. This meant that a service
could be started when configured to use a relative pid file, but
then could not be stopped.
The PID folder should be treated as relative to the service's jar
file. This commit updates stop, status, and force_reload to push the
jar file's directory so that this is now the case for those three
commands.
Closes gh-7092
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
Andy Wilkinson
Phillip Webb
Gaurav Rawat
Spring Buildmaster
Johnny Lim
Vedran Pavic
Stephane Nicoll