Add support for a new annotation, @GrabMetadata, that can be used
to provide the coordinates of one or more properties files, such as
the one published by Spring IO Platform, as a source of dependency
metadata. For example:
@GrabMetadata("com.example:metadata:1.0.0")
The referenced properties files must be in the format
group:module=version.
Limitations:
- Only a single @GrabMetadata annotation is supported
- The referenced properties file must be accessible in one of the
default repositories, i.e. it cannot be accessed in a repository
that's added using @GrabResolver
Closes#814
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 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
There was an issue with the generated poms for the dependency
tools (I'm not sure the generation step works if you don't
do "mvn clean"). Anyway I verified that it works and removed
the (now) unnecessary provided dependency from spring-boot-cli.
Fixes gh-362
Reverting arguments in assertEquals where constant was placed on
the "actual" place. Replacing assertEquals with assertFalse, assertTrue
and assertNull where applicable.
Fixes gh-735
If a source URL is added to a CompilationUnit and that source URL does
not contain any slashes, the resulting ClassNode in the AST will be
incorrectly named. For example, a URL of 'file:foo.groovy' will produce
a ClassNode named 'file:foo'. The expected name is 'foo'.
This commit works around this problem by adding any URL sources with a
file protocol to the compilation unit as File instances. Any URL sources
that do not have a file protocol continue to be added as URL instances.
Such URLs are still prone to this bug should we be dealing with one
that contains no slashes. A fix for the underlying Groovy bug will
address this possibility.
Fixes#594
This commit updates the CLI so that it will decrypt any encrypted
passwords in a user's Maven settings.xml file.
The code that performs the decrytion has a transitive dependency on
three types in Plexus' logging API. There are tens of different
artifacts containing this API available in Maven Central. Rather than
bloating the API with a dependency on a complete Plexus container,
which could perhaps be considered the primary source, a dependency on
a considerably smaller artifact has been introduced.
Closes#574
If the user adds a JAR file to the classpath in "spring jar -cp ..."
he expected it to end up in the classpath of the executable jar
(i.e. in the nested lib/ directory). Before this change it would
have gone in the root of the executable JAR, causing errors at runtime.
The fix is slightly awkward, since it assumes that any JAR in the
"roots" of the ResourceMatcher come from the classpath (which *is*
the case currently, but might not always be at least in principle).
Seems like a reasonable compromise given it's a quick change
and some tests have been included.
Fixes gh-565
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
Boot promotes the use of a templates directory for housing view
templates. Include this directory by default when building a jar file
from a CLI app.
Fixes#455
Explicitly link to install.txt in source repo to avoid issues on projects.spring.io with a broken relative link
... also fix this for rendered markdown on GH itself :-)
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