Instead of *always* needing to pull auto-import dependencies
from the master parent pom, we now allow normal @Grab-style
module specifications, e.g. "io.ratpack:ratpack-groovy:0.9.2"
The issue was that the JreProxySelector was only applied
if the existing selector was null, but that hasn't been the case
since we added supporty for settings.xml. The strategy now is to
fallback to a JreProxySelector if the existing one is null
or not already a composite. Fixes gh-914.
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).
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
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
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
Update the CLI Groovy InnerLoader to not expose URLs. This prevents the
'TLD skipped' log messages from Tomcat that occurred previously due to
the InnerLoader and parent returning the same URLs.
Fixes gh-277
Change CLI generated JARs to use the standard `JarLauncher` instead of
a custom `JarRunner`. The `PackagedSpringApplicationLauncher` is used
as the `Start-Class` which in turn calls `SpringApplication.run()`.
A new command, jar, has been added to the CLI. The command can be
used to create a self-contained executable JAR file from a CLI app.
Basic usage is:
spring jar <jar-name> <source-files>
For example:
spring jar my-app.jar *.groovy
The resulting jar will contain the classes generated by compiling the
source files, all of the application's dependencies, and entries
on the application's classpath.
By default a CLI application has the current working directory on
its classpath. This can be overridden using the --classpath option.
Any file that is referenced directly by the classpath is always
included in the jar. Any file that is found a result of being
contained within a directory that is on the classpath is subject to
filtering to determine whether or not it should be included. The
default includes are public/**, static/**, resources/**,
META-INF/**, *. The default excludes are .*, repository/**, build/**,
target/**. To be included in the jar, a file must match one of the
includes and none of the excludes. The filters can be overridden using
the --include and --exclude options.
Closes#241
By convention, Ruby code is indented using two spaces ( ) per-level.
The code used tabs (\t) previously and therefore wasn't idiomatic.
This change updates the indenting to use two spaces.
This change adds support for --HEAD builds to the Homebrew formula. It
defines a conditional dependency on Maven and builds the -cli project
during install. The location to install from is abstracted out so
that code is identical regardless of whether the build is --HEAD or
mainline.
