The test passes locally, both in Eclipse and on the command line, but
fails on the CI server. Revert the addition of the test while I
hopefully figure out why.
This reverts commit 2e81b1d0d0.
The grab command downloads the dependencies of one or more Groovy
scripts to ./repository. This commit ensures that those previously
downloaded dependencies can be used by a subsequent invocation of the
run command.
The location and behaviour of the local cache is unaffected by this
change. If the dependencies in ./repository do not exist in the local
cache, Aether will "download" them from ./repository and store them in
the local cache.
Fixes#191
Previously, Aether's configuration was largely hard-coded making it
impossible to configure a mirror, provide credentials for accessing
a repository, etc.
This commit adds support for configuring Aether via Maven's
settings.xml file. The support is optional and must be enabled by
grabbing spring-boot-maven-settings in an init script. The Aether
instance that's used when running the application will then be
configured using settings.xml. The settings file is expected to be
found in ${user.home}/.m2/settings.xml.
The configuration of the following items is currently supported:
- Offline
- Proxies
- Mirrors
- Server authentication
- Local repository location
If the support is not enabled, settings.xml does not exist, or
settings.xml does not configure certain things then sensible defaults
are applied.
When an init command is run, it may add entries to the classpath. This
commit adds a test that verifies that, if an entry that is added to
the classpath contains a CompilerAutoConfiguration file in
META-INF/services, then the CompilerAutoConfigurations declared in it
are found by subsequent ServiceLoader.load calls.
Also logs a warning about the fact that locks may not be taken when
starting a Job. JPA and Batch don't really work that well together
in general so it's probably not worth a lot of effort to work aoround
this. If anyone needs to they should create a custom JpaDialect
(and a BatchConfigurer).
Fixes gh-197
Previous fix for handling wildcard entries in a classpath
imposed a new problem in a case where entry is a directory
with a jar files but also contains a lot of nested directories.
For example entry "./*" resulted for scanning whole disk starting
from "/". In case of default hadoop classpath, it scanned everything
under hadoop's installation. On some cases this deep scan was hidden
and was revealed by NPE's for file access exceptions.
When we want to support wildcard entries we only want to get
jar files from that directory, while boot itself have a need
to travel recursively to find classfiles from an expoded archive.
We handle this case by using recursive(true by default) flag in
ExplodedArchive and this flag is set to false in PropertiesLauncher
if we match wildcard.
Previously, a transform was used to add @GrabResolver annotations
during compilation that added the Spring milestone and snapshot
repositories. This functionality is now handled by
RepositoryConfigurationFactory so the transform is no longer required.
Fix the following issues that were introduced in commit 0610378:
- Formatting of code including imports
- Improve hashcode/equals implementations by using ObjectUtils
- Provide hashcode/equals for ConditionOutcome
- Use LinkedHashSet in ConditionAndOutcomes to maintain insert order
Fixed gh-127
Users can declare or Command, OptionHandler classes in an init script
or they can use a DSL, e.g.
command("foo") { args -> println "Do stuff with ${args} array" }
or
command("foo") {
options { option "bar", "Help text for bar option" ithOptionArg() ofType Integer }
run { options -> println "Do stuff with ${options.valueOf('bar')}" }
}
InitCommand runs on creation of SpringCli so it can search for additional
Commands in updated classpath. Also added as interactive command in Shell
session.
PropertiesLauncher now supports creating its own class loader
from looader.classLoader property. It will succeed if the
implementation specified has a default constructor or one
that takes a parent class loader, or one that takes a URL[]
and a parent class loader (like URLClassLoader).
The collection of outcomes is a list. Sometimes a race condition causes to instances
of the same outcome to get added to the list shown in the report. By replacing this
with a set and propery equals/hashCode, duplicates are prevented from appearing
in the report.
I added test cases to prove that that POJO is properly managed inside a Set and also
to show that duplicates don't appear in the final report.
Autoconfiguration ordering has to be adjusted so that a DataSource is
available before an EntityManagerFactory is ever needed. Previously
the autoconfigs were accidentally loaded in the right order, but after
the change to BatchAutoConfiguration the order has to be explicit.
Fixes gh-189
Change SpringCli so that running without arguments no longer jumps into
the embedded REPL shell. This restores the ability to obtain quick usage
help by simply typing `spring` from the command prompt.
Windows users or developers that prefer the embedded shell can still
launch it using `spring shell`.
Change OptionHandler to support '-cp' instead of '--cp'. This update
to the original fix (045088e8b) renders `help` output correctly and
should prevent potential issues if a `-p` command is added in the future.
Fixes gh-178
Defer loading of Servlets (with a loadOnStartup priority) until
the `EmbeddedServletContainer.start()` method is called. This prevents
issues with the DispatcherServlet being initialized before the embedded
ApplicationContext is fully initialized.
Long package names are really unnecessary in samples and they
just clutter things up. Also Spring Loaded doesn't work with
org.sfw packages, so to demo that technology you need a
different package name.
Main user-facing interface is still Counter/GaugeService but the
back end behind that has more options. The Default*Services write
metrics to a MetricWriter and there are some variants of that, and
also variants of MetricReader (basic read-only actions).
MetricRepository is now a combination of MetricReader, MetricWriter
and some more methods that make it a bit more repository like.
There is also a MultiMetricReader and a MultiMetricRepository for
the common case where metrics are stored in related (often open
ended) groups. Examples would be complex metrics like histograms
and "rich" metrics with averages and statistics attached (which
are both closed) and "field counters" which count the occurrences
of values of a particular named field or slot in an incoming message
(e.g. counting Twitter hastags, open ended).
In memory and redis implementations are provided for the repositories.
Generally speaking the in memory repository should be used as a
local buffer and then scheduled "exports" can be executed to copy
metric values accross to a remote repository for aggregation.
There is an Exporter interface to support this and a few implementations
dealing with different strategies for storing the results (singly or
grouped).
Codahale metrics are also supported through the MetricWriter interface.
Currently implemented through a naming convention (since Codahale has
a fixed object model this makes sense): metrics beginning with "histogram"
are Histograms, "timer" for Timers, "meter" for Meters etc.
Support for message driven metric consumption and production are provided
through a MetricWriterMessageHandler and a MessageChannelMetricWriter.
No support yet for pagination in the repositories, or for HATEOAS style
HTTP endpoints.
Andy Wilkinson
Dave Syer
Janne Valkealahti
Phillip Webb
Greg Turnquist