Update spring-boot-dependency-tools to support transitive excludes.
Transitive excludes are useful with Gradle which considers each
dependency independently (see GRADLE-3061).
Transitive excludes are supported by parsing the dependency-tree file
from spring-boot-versions.
See gh-1047
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.
The main difference for now is the removal of the --nohup
(slightly hacky) option in TestCommand. Now a TestCommand
can signal to its caller that it wants to be hung up.
Fixes gh-975
Restore the dependency on commons-logging (transitively via spring-core)
for spring-boot. This means that we are not tied directly to SLF4J, but
it is still an option that can be used via `jcl-over-slf4j`.
The `spring-boot-starter-parent` continues to replace `commons-logging`
with `jcl-over-slf4j`.
Fixes gh-981
Unify the versions used in integration tests launched by the
maven-invoker-plugin. Allows for already cached local copies to be
used, hopefully speeding up the build.
Unify the versions used in integration tests launched by the
maven-invoker-plugin. Allows for already cached local copies to be
used, hopefully speeding up the build.
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
ExecutableArchiveLauncher creates a ClassLoader that is used by the
Launcher to load an application’s classes. During the creation of this
ClassLoader URLs from another ClassLoader are copied over. This was
resulting in Java agents that are added to the system class loader
via the -javaagent launch option being available on both the system
class loader and the created class loader. Java agents are intended to
always be loaded by the system class loader. Making them available on
another class loader breaks this model.
This commit updates ExecutableArchiveLauncher so that it skips the URLs
of any Java agents (found by examining the JVM’s input arguments) when
copying URLs over to the new classloader, thereby ensuring that Java
agents are only ever loaded by the system class loader.
Fixes#863
Add a new maven project containing a versions.properties file and
an effective POM. Rework existing projects to use the versions
artifacts.
Partially reverts 307fbba9e4
Fixes gh-913
Previously spring-boot-dependency-tools used spring-boot-tools as its
parent. This meant that it inherited spring-boot-parents' dependency
management that we did not want to expose to applications. The
solution to this was to generate the effective pom and then filter
out any thing that did not appear in spring-boot-dependencies' pom.
This filtering had to unwanted side-effect of breaking bom imports:
the effective pom would contain the dependency management from the
imported bom, but this would be filtered out as the entries didn't
appear in spring-boot-dependencies' pom.
This commit updates spring-boot-dependency-tools to use
spring-boot-dependencies as its parent. This means that its effective
pom contains the desired dependency management and nothing more,
allowing the filtering logic to be removed.
The use of Spring Security's bom has been reinstated as it will now
work as intended and versions for its modules will be available in the
CLI and via the Gradle plugin.
Closes#825Fixes#838
Previous to this commit, any groupId starting with one of the
configured exclude would be excluded as well. This potentially
leads to unintentional dependency filtering: for example the
GroupIdFilter with an exclusion of "org.springframework"
also removes "org.springframework.boot" dependencies.
Add MatchingGroupIdFilter that uses an exact match instead.
See #649
The problem all along has been in AsciiBytes, so the fix in
commit ce3aaf was just a stop gap for a system where multi-byte
characters are supported but the default encoding is not UTF-8 (e.g.
most Windows systems). The real solution is not to leave it to
chance and always pick an encoding for the JarEntry names (i.e.
in AsciiBytes).
(Cherry picked from commit 06e364a9ff)
Fixes gh-764
If an execution of the repackage goal is present in a project with
'pom' packaging, it is now skipped. This allows to configure the
plugin in the parent.
Fixes gh-867
The configuration within an execution is only applied when that
particular execution is invoked as part of the build. It is not
applied when the plugin is invoked on the command line (i.e.
mvn spring-boot:run).
This commit clarifies the situation so that users can safely copy/paste
those bits and get the expected behavior.
Fixes gh-875
The maven plugin now forks a new process when it starts a boot app. This
makes remote debugging of the app impossible without the ability to pass
extra JVM arguments.
This commit adds a "jvmArguments" attribute to the RunMojo that defines
additional JVM arguments to set on the forked process.
Fixes gh-848
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 (empirically) fixes gh-726 using a new utility
(LogbackInitializer) in the loader tools. If anyone has enough
Gradle fu to understand where to put it (after the classpath is established
but before compilation) we could do the same thing in the Gradle plugin
(and that would fix gh-724).
This commit provides several options to exclude one or more
dependencies:
* excludes allows to specify an arbitrary number of exclude sub
element defining the groupId and artifactId of the dependency
to exclude
* excludedGroupIds defines the comma separated list of groupIds
to exclude
* excludeArtifactIds defines the comma separated list of artifactIds
to exclude
While any artifact can be excluded, this is designed to exclude
provided-scoped dependencies that should not be bundled in the
executable jar/war.
The outcome of java -jar myapp.jar should be consistent with the run
goal: these exclusions are therefore applied to the classpath that
the run goal computes to launch the application.
This commit also adds some integration tests and updates the
plugin's documentation
Fixes gh-649, gh-650 and gh-674
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
Commit e26e06d5dd broke the full build as the generated zip file for
the size is not generated. Actually, the site plugin has a jar goal that
is exactly meant for what we need to do.
This commit removes the use of the assembly plugin and invokes the
jar goal of the site plugin when the full profile is enabled.
Relates to #749
This commit adds the generated site for the maven plugin alongside
the developer guide and javadoc. The maven plugin is available in
the "/maven-plugin" context.
The advanced information described in the developer guide have
been migrated to the plugin site as most the information is taken
from the code itself, which avoids duplication.
Fixes#749
The problem all along has been in AsciiBytes, so the fix in
commit ce3aaf was just a stop gap for a system where multi-byte
characters are supported but the default encoding is not UTF-8 (e.g.
most Windows systems). The real solution is not to leave it to
chance and always pick an encoding for the JarEntry names (i.e.
in AsciiBytes).
Fixes gh-764
There were several problems to fix. 1) a bug in the
JDK (1.7 up to 7_60):
https://bugs.openjdk.java.net/browse/JDK-8023130
which we can work around by detecting buggy VMs and not trying
to use inheritIO. 2) File<->URL conversion is platform dependent
and we shouldn't make any assumptions. The problem in this case
was that file URLs contain a ":" so they can 't be added to a
path in UNIX, but on Windows you need the absolute path with the
colon. Solution: use Files on the classpath for spring-boot:run.
Hopefully also fixes gh-767
The encoding of UTF-8 (et al.) chars in the
JarUrlConnection has to be made explicit, otherwise
Wdinows apparently does not pick the default(?).
Fixes gh-711, Fixes gh-753
The encoding of UTF-8 (et al.) chars in the
JarUrlConnection has to be made explicit, otherwise
Wdinows apparently does not pick the default(?).
Fixes gh-711, Fixes gh-753
Reverting arguments in assertEquals where constant was placed on
the "actual" place. Replacing assertEquals with assertFalse, assertTrue
and assertNull where applicable.
Fixes gh-735
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
Before this change we were too aggressive in deleting duplicate resources
since directories might not have identical contents, and yet they were
being deleted anyway.
Fixes gh-614
Update the spring-boot-loader JarURLConnection class to decode entry
names in the same way as the stock JDK class. This allows encoded
entry names in the form `%c3%ab` to be loaded.
Fixes gh-556
Change the initial fix for OSX Java 1.6 compatibility by removing the
need for a direct `tools.jar` dependency.
It appears that `system` dependencies are always pulled in when
used in a Maven plugin. This makes the the dependency on `tools.jar`
particularly brittle since we need to make assumptions about where
the jar is located.
Since the tools jar is *only* needed for Spring Loaded support, the
plugin has now been updated to locate the jar programmatically and
call it via reflection. This should reduce the risk of problems when
using the plugin and at the very least isolate them to Spring Loaded
support.
(See original commit b8c4720)
Fixes gh-497
It is sufficient for most purposes (e.g. the ones PropertieLauncher needs)
to only read the META-INF directory (not the whole file tree). So a quick
fix is to make META-INF a special case when initializing non-recursive
entries.
Fixes gh-520
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
Currently Spring Boot fails in Java 1.6 on Mac OS X due to the
"tools.jar" being integrated into classes.jar in the Apple version of
Java 6.
Apple fixed this with Java 7, but we should still support Java 6. We had
to roll back to maven-plugin-plugin 3.1 to make this work with Java 6
and 7.
All tests pass with Java 6 and Java 7.
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
The source of the exception is in sun.misc (so hard to track down precisely)
but it's clear that the LaunchedJarURLClassLoader needs to be more
defensive and return null from findResource() if it can't find it.
Fixes gh-486
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
This turns out to affect JPA, but only because it looks for a URL for the
root of the classpath using ClassLoader.getResource("") which barfs in
an app launched from an executable JAR. It's easy to make a special case
for "" in the class loader, so I went ahead and did that. Possibly need
to think what the implication of getResources("") is as well (not
tested in an app yet).
Fixes gh-420
It turns out that loader.path=. was pathological and before this
change ended up making the classpath empty (loader.path=.,lib/
would have fixed it). With this change the old behaviour is still
supported, but if the only user-supplied path entry is "." (or
empty) then it is now kept, and translates into the root of the
current archive if running as "java -jar ...".
Fixes gh-270
Restore previous behavior where JarFile URLs are always prefixed with
"jar:". I believe that the prefix is required in order to remain
compatible with standard JAR URLs.
This reverts commit 825fc2f7df.