* See SpringApplication.setDefaultCommandLineArgs
* Assumes command line is in "simple" form (TODO: if we
need JOpt etc. support then the command line args parsing from
Spring needs to be exposed)
* If defaults are provided the command line might be re-ordered
slightly (non-option args come after option args)
* Allows custom application.properties file names to be specified
as a side effect (--spring.config.name=... or
--spring.config.location=...}.
[Fixes#48284369]
$ cd spring-bootstrap-cli
$ export SPRING_HOME=target
$ src/main/scripts/spring run samples/integration.groovy
The big disadvantage at the moment is that there is no goo way to
detect Spring Integration in the AST (at least not as good as @Enable*).
So for now we are looking for @MessageEndpoint or a class name with
SpringIntegration in it.
[#48151147]
Apparently an anonymous class in Groovy is no anonymous in the compiled code,
so we need another heuristic. We now check for non-existence of public
constructors (if there are none then there's no point regsistering that
class with an application context).
[#48718891]
* Added a test for each of the classes loaded by the SpringApplication
* If it's an anonymous class or looks like a Groovy closure we ignore it
* The CLI sample job.groovy also modified to take advantage
[Fixes#48718891]
We could take this out again when we decide what to do about plugins
but it's good to have it in for now because it shows how to do it,
and exposes some holes. The job.groovy script now works, but
a lot of it should be defaulted through auto-configuration.
(See also [bs-73] for a non-Batch related bug.)
[#48716881]
* Also added "spring" shell script (in zip), so you can
unzip it and run out of the box
* To run in developer mode use SPRING_HOME, e.g.
$ cd spring-bootstrap-cli
$ SPRING_HOME=target src/main/scripts/spring run samples/web.groovy
* Also added "clean" command to remove spring bootstrap grapes
(useful to force a refresh of snapshot jars)
[#48644271]
Dave Syer
Phillip Webb