$ ant -lib ivy-2.2.jar

(substitute the location of your actual ivy jar)

    $ java -jar target/*.jar

Fixes gh-140

Fixes gh-181

User can now do this, for instance:

    @Configuration
    @PropertySource("classpath:my.properties")
    public class MainConfiguration {}

    @Configuration
    @PropertySource("classpath:foo.properties")
    @Profile("foo")
    public class FooConfiguration {}

and the "foo" properties ar eonly loaded in the "foo" profile.

If any of the sources has a @PropertySource annotation (or many)
then we can add those properties to the Environment. It's a nice
convenient way of specifying a custom external properties location
for an app.

One problem is that Spring will come along and parse the same
annotations later as part of the @Configuration parsing. The
user has pretty limited control over how that is done, and it
will never be done in a "natural" way for a Boot application
(which would prefer that the default application.properties
is applied *last*, whereas Spring will apply the @PropertySource
last).

To get round that problem we add the property sources with
a different name (key in the PropertySources in Environment),
prefixing named property sources with "boot.", and adding
others with a name that is the same as the resource location
(instead of its description, which is the default for
Spring).

Another problem is that Spring doesn't know about YAML, so
the user is currently restricted to using properties files
with this annotation.

We still need the distinction internally between initial and additional
sources, but the SpringApplication API (getSources()) itself doen't
need to reflect that.

* when run 'java org.springframework.boot.loader.JarLauncher'

Fixes gh-176

We get more control over the handling and in particular the registration
of the endpoint this way. It was practically impossible to disable the
AgentServlet bean when in a parent context of the management server
because of lifecyce issues - you don't know that the user wants a
separate management server until too late.

This approach also makes it possible to test with spring-test MVC
support.

Renamed javadoc to a general purpose docs project that can be
automatically deployed.

User can add (a single) beans{} DSL declaration (see GroovyBeanDefinitionReader
in Spring 4 for more detail) anywhere at the top level of an application source
file. It will be compiled to a closure and fed in to the application context
through a GroovyBeanDefinitionReader. Cool!

The example spring-boot-cli/samples/beans.groovy runs in an integration test
and passes (see SampleIntegrationTests).

Rename invoke JMX operation to getData for endpoints that provide actuator data. Special case for ShutdownEndpoint to provide a shutdown method.

Change JmxAutoConfiguration so that by default JMX exposure is not
enabled. This matches the Javdoc text.

Change strategy from ApplicationListener to SmartLifecycle to avoid multiple registration attempts for the same beans

When running with parent/child application contexts the previous implementation was trying to re-register the same beans with JMX which led to errors.