3d714d301 allowed all integration tests to download snapshots and
milestones. The test for the integration sample, which depends upon a
milestone, no longer needs to be a special case.
Previously, GrapeEngineInstaller would only install its GrapeEngine
if an engine had not already been installed. As the Grape class stores
the engine in a static field, this meant that the engine would only be
installed once for the lifetime of Grape's classloader. This caused
an ordering issue in SampleIntegrationTests.
The test for the integration sample clears the
disableSpringSnapshotRepos system property to allow M1 of the
integration DSL to be resolved. However, this property is only
examined and honoured in AetherGrapeEngine's constructor. If another
test had run and had already created and installed an
AetherGrapeEngine, the new AetherGrapeEngine that allowed the use of
snapshot repositories would not be installed and the test would fail.
This commit updates GrapeEngineInstaller so that it always installs
its GrapeEngine, overwriting any previously installed engine.
Previously, the Ivy-based Grape engine used a system property,
disableSpringSnapshotRepos, to control whether or not Spring's
snapshot and milestone repositories were used for dependency
resolution. This commit adds the same capability to AetherGrapeEngine.
[#59489826]
@Grab allows a dependency to be declared, but for its transitive
dependencies to be excluded by setting transitive to false. This
commit enhances AetherGrapeEngine to honour this setting by using a
wildcard exclusion on any dependency so declared.
Prior to this commit, the Aether-based GrapeEngine was loaded in the
same class loader as the rest of Boot. This led to Aether's and its
dependencies' types polluting the application's class path. Most
notably, this caused problems with logging as the logging framework
could be permaturely initialized.
This commit isolates AetherGrapeEngine, Aether and its dependencies
into a separate class loader. This is done by customizing the
packaging of the CLI's jar file with the internal directory housing
all of the types that will be loaded by the separate class loader.
Previously, @Grab annotations would use Ivy to download the
dependencies with some of Ivy's known limitations being worked around
by GrapeEngineCustomizer.
This commit adds a GrapeEngine implementation that uses Aether,
the dependency resolution 'engine' used by Maven and Grails. To ensure
consistent behaviour with a Maven build, the Aether-powered dependency
resolution uses the dependency management configuration from the
spring-boot-starter-parent pom file.
Previously, simple @Grab annotations only worked on classes. This commit
updates the simple @Grab support so that they can be used on anything
that can be annotated with @Grab.
The simplified @Grab support relies upon springcli.properties having
been generated. This commit adds an M2E lifecycle mapping for the
antrun plugin so that springcli.properties is generated as part of an
Eclipse build, thereby making it easier to run tests in Eclipse that
rely upon the simplified @Grab support.
Previously, LocalM2Resource used the pom's packaging configuration to
determine the suffix of the file that it should look for, e.g. if
the pom's packaging was jar, it would look for a file with a .jar
suffix in artifactExists(). This logic fails for artifacts with bundle
packaging as it would look for a .bundle file rather than a .jar file,
fail to find the file, and incorrectly report that the artifact does not
exist.
This commit updates LocalM2Resource to look for a file with a .jar
suffix when the packaging configuration in the pom is bundle.
- Look for JUnit test symbols, and add JUnit automatically
- Look for Spock test symbols, and add Spock automatically
- Based on what test libraries were used, invoke relevant embedded testers
and accumulate results
- Make it so that multiple testers can be invoked through a single 'test' command
- Print out total results and write out detailed trace errors in results.txt
- Update based on the new artifact resolution mechanism
Usually, use of @Grab requires you to specify a group, module, and
version when identifying a dependency. This can be done in two
different ways:
@Grab(group='alpha', module='bravo', version='1.0.0')
@Grab('alpha:bravo:1.0.0')
This commit allows users to only specify a module: the group is
inferred and the version is the one dictated by the boot CLI. Both
forms are supported:
@Grab(module='bravo')
@Grab('bravo')
Groovy's global AST transformations, which is how Grab is implemented,
do not support ordering and we need to augment the AST for the Grab
annotation before its processed by the Grab AST transformation. To
work around this, reflection is used to get hold of the compile
operations in the conversion phase, and a new AST transformation is
inserted immediately before the first AST transformation operation.
To allow a module's groupId and version to be resolved consistently,
META-INF/springcli.properties has been enhanced to include properties
for each module that we want to support in the following form:
<module>.groudId = <groudId>
<module>.version = <version>
<groupId> and <version> are taken from the Maven project's
dependencies and VPP, a Velocity-based pre-processor, is used to
automatically generate the enhanced properties file.
To prevent pollution of spring-boot-cli's class path with the
dependencies that are only required to populate springcli.properties,
a separate project, spring-boot-cli-properties, has been created.
spring-boot-cli depends upon this now project causing it to, via the
shade plug, include the properties file in its jar.
Previously DependencyCustomizer allow a dependency to be added by
specifying its full coordinates, i.e. a group ID, artifact ID, and
version. This commit updates DependencyCustomizer to only require
an artifact/module ID. The group ID and version are then resolved
using the same mechanism as the enhanced @Grab support.
[#56328644] [bs-312] Allow @Grab without version
- If RabbitTemplate is on the classpath, turn on autodetection.
- Create a RabbitTemplate, a Rabbit ConnectionFactory, and a RabbitAdmin is spring.rabbitmq.dynamic:true
- Enable some **spring.rabbitmq** properties like host, port, username, password, and dynamic
- Add tests to verify functionality
- Add Groovy CLI functionality. Base it on @EnableRabbitMessaging. Add spring-amqp to the path.
- Create rabbit.groovy test to prove it all works.
- Make Queue and TopicExchange top-level Spring beans in rabbit.groovy test script
* application.properties support for spring.jms and spring.activemq
* more tests to verify ActiveMQConnectionFactory pooling
* Groovy support and simple sample with activemq
* Groovy detection mechanism is @EnableJmsMessaging annotation
* Add ability to detect spring-jms on the path and create a JmsTemplate with
ActiveMQConnectionFactory
* Create tests showing autoconfigured JmsTemplate with ActiveMQ, but prove it
backs off if a separate ConnectionFactory exists.
* Add support to spring-boot-cli to that it detects JmsTemplate, DefaultMessageListenerContainer,
or SimpleMessageListenerContainer, and turns on autoconfiguration as well as
add proper @Grab's and import statements.
* Write a jms.groovy test showing proper CLI support
Simplify ActiveMQ configuration
Update ActiveMQ to 5.7.0
* @EnableTransactionManagement triggers spring-tx imports
* Field or method of type JdbcTemplate or NamedParameterJdbcTemplate
of DataSource triggers spring-jdbc imports
Andy Wilkinson
Phillip Webb
Dave Syer
Roy Clarkson
Greg Turnquist
Christian Dupuis