Previously, InstallCommand used a custom Grape root and then walked
the tree of files downloaded by Aether to determine which files it
should install or uninstall. In some scenarios two files for the
same module would be present: one named foo-1.0.0.BUILD-SNAPSHOT.jar
and one named foo-1.0.0.BUILD-20140905.091809-2.jar. The former is
from the local repository and the later is from a remote repository.
In this case, the visitor would do the wrong thing and the latter
would be installed into lib.
This commit updates InstallCommand to determine the jars that it
should process by consulting GroovyCompiler's classpath, rather than
by walking Aether's cache. This approach selects the correct jar as
Aether has already figured this out as part of resolving the
dependency. It also brings InstallCommand into line with JarCommand.
The previous implementation used Java 7-specific File APIs. As part
of the above-described change this usage has been removed. The
install command can now be used on Java 6.
Fixes gh-1515
This commit avoids a script duplication: the integration test runs the
sample instead of a copy of it in the repro directory.
Also switched the sample from ActiveMQ to HornetQ as #323 revealed
some locking on CI. Hopefully that should fix it as HornetQ is non
persistent and can be embedded several times in the same VM.
Fixes gh-1456
This commit deprecates the proprietary EnableJmsMessaging annotation in
favour of the standard @EnableJms introduced as of Spring 4.1. This
commit also updates the sample and adds an integration test as the
feature was actually broken.
Fixes gh-1456
Previously, the CLI relied on Aether using the session's mirror
selector and authentication selector to customize the configured
repositories. These selectors are only used to configure what Aether
calls recessive repositories (repositories discovered when resolving
an artifact), rather than the explicitly configured repositories that
are typically used.
This commit updates AetherGrapeEngine to apply mirror and
authentication configuration to every added repository, bringing its
behaviour for these two settings into line with what it already does
for proxy configuration.
Fixes#1354
Since all dependencies are local in a jar there is no need for
a GrabResolver (and it breaks the app because the default ivy
GrapeEngine is used instead of the smart, pretty Boot one).
Fixes gh-1179
Update the executable JAR code to automatically unpack any entries
which include an entry comment starting `UNPACK:` to the temp folder.
The existing Maven and Gradle plugins have been updated with new
configuration options and the `spring-boot-tools` project has been
updated to write the appropriate entry comment based on a flag passed
in via the `Library` class.
This support has been added to allow libraries such a JRuby (which
assumes that `jruby-complete.jar` is always accessible as file) to work
with Spring Boot executable jars.
Fixes gh-1070
The lists are comma separated. In addition, user can add prefixes
"+" or "-", to signal that those values should be removed from the
default list, not added to a fresh one. E.g.
$ spring jar app.jar --include lib/*.jar,-static/** --exclude -**/*.jar
to include a jar file specifically, and make sure it is not excluded,
and additionally not include the static/** resources that would otherwise
be included in the defaults. As soon as "+" or "-" prefixes are detected
the default entries are all added (except the ones exlcuded with "-").
Fixes gh-1090
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
In the absence of a @GrabMetadata annotation,
DependencyResolutionContext provided no dependency management. This
was leading to incorrect dependency versions being pulled in. This
commit intializes the context with default dependency management that
will be replaced should @GrabMetadata be encountered.
Fixes#1021
We currently honour type, but ignore ext. Aether doesn't make a
distinction between the two so a Grab that specifies both type and ext
but with different values is considered to be an error.
Fixes#995
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
Actually the web-secure sample is misusing
security.basic.enabled=false (IMO) - it should be a flag
to say that you want to temporarily disable the basic security
fallback on application endpoins, not way to disable all
security autoconfiguration.
Added test case to web-secure sample to ensure a user
can log in.
Fixes gh-979
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
Otherwise the ApplicationContext stays alive and if it's a
server app the JVM does not exit at the end of "spring test".
User can override with "spring test foo.groovy --nohup"
(which we have to do in our unit tests).
Update Spring Social auto-configurations to read properties using
the `dashed` notation and with the appropriate prefixes. This allows
properties to be specified in any of the relaxed forms.
Also minor refactor to extract common logic to a new
SocialAutoConfigurerAdapter base class.
See gh-941
Up to now we have been treating the *first* class to be compiled
as the "main" application and adding @EnableAutoConfiguration. This
isn't always appropriate (e.g. if it's a test case), so now we
look for an appropriate annotation before falling back to the old
behaviour.
In addition ensures classes with a field of type Reactor trigger
the reactor auto imports.
See gh-969
JUnit tests can now be @SpringApplicationConfiguration
and @IntegrationTest without any explicit imports. Also
makes @RunWith(SpringJUnit4ClassRunner) optional.
Fixes gh-969
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).
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
Andy Wilkinson
Spring Buildmaster
Phillip Webb
Dave Syer
Stephane Nicoll
Andy Wilkinson
Phillip Webb
Dave Syer
Stephane Nicoll
Craig Walls
Gary Russell
Artem Bilan
sopov.ivan
Andy Piper
Sebastien Deleuze
Christian Dupuis