Summary: Tomcat works with WARs. Jetty doesn't work.

See gh-367

Fixes gh-366

Requires Loaded 1.1.5 (or better).

For Maven you can just add springloaded to the dependencies of the
spring-boot plugin (and also set MAVEN_OPTS=-noverify).

For Gradle add springloaded to the build dependencies (-noverify
can be added by the plugin).

In both cases there is also support for adding an arbitrary java agent
via configuration. Samples are provided in
spring-boot-sample-[simple,web-ui].

The ApplicationPlugin is only added if there is no JavaExec task
already present, and additionally it computes its own man class if
none is provided. So "gradle run" and "gradle bootRun" look
superficially similar, but "bootRun" has extra options, including
the agent and Loaded support.

Fixes gh-251, gh-183

In particular don't assume that Spring Security Web is on the
classpath, just because Spring Security Core is.

Fixes gh-363

Update OnBeanCondition to attempt to consider FactoryBean classes
for bean type matches. To ensure early instantiation does not occur, the
object type from the FactoryBean is deduced by resolving generics on the
declaration.

Fixes gh-355

Here's what I think works best:

* Any profile in the Environment before application.yml
is processed takes precedence (i.e. it will be last in the
list of active profiles in the live app)

* Any profile in the Environment before SpringApplication
starts takes precedence (so any added on the command line or
with System properties come after ones added using
the SpringApplication API)

* The order of profiles in application.yml is irrelevant -
profiles are applied in the order they come out of
Environment.getActiveProfiles()

Fixes gh-342

The command line profile (or equivalently System property) is
not winning right now. Arguably that should be fixed. (Thinking...)

Relevant to gh-342

 - spring-integration-core 3.0.1.RELEASE (closes #360)
 - Logback 1.1.1 (closes #361)
 - maven-settings-builder 3.1.1 (closes #359)
 - maven-aether-provider 3.1.1 (closes #356)
 - jopt-simple 4.6 (closes #357)
 - SLF4J 1.7.6 (closes #318)

Ordering: profiles are applied in order (from the active profiles
list in the Environment), with the last one winning as far as
property values goes. This *does* mean that a profile activated
inside application.yml is applied last and hence takes precedence.
It's debatable whether that is the right semantics, but that's
what it is for now.

Re gh-342: a profile added via SpringApplication also takes
precedence over one added on the command line. Also debatable
but at least it's predictable.

Naming: a profile adds "#<profile>" to the end of a property source
name (no more, no less)

In response to gh-352

Update the executable JAR `Handler` to fallback to the JVM handler if
the jar cannot be opened. This prevents exceptions when trying to
open URLs in the form "jar:jndi:/localhost...".

Fixes gh-347

Fix ConfigFileApplicationListener to correctly bind
`application.properties` to SpringApplication. Binding in RC2 failed
due to the fact that `ConfigurationPropertySources` did not extend
`EnumerablePropertySource`.

Fixes gh-346

Rename EnvironmentDelegateApplicationContextInitializer to
DelegatingApplicationListener and EnvironmentDelegateApplicationListener
to DelegatingApplicationListener.

Reintroduce ConfigFileApplicationContextInitializer for tests that
wish to reuse 'application.properties' configuration.

Fixes gh-344

Improve package structure and include package-info javadoc.

This reverts commit 89283e46.

Revert until we can find a new home, outside of the usual build
process.

Fix ConfigFileApplicationListener to load profile specific files
(*-profile.ext) both as a root document, and again with the profile
active.

This allows profile specific files to still include a 'spring.profiles'
property if they wish.

Issue: gh-340

Run with "mvn spring-boot:run" and then scrape the Markdown from stdout.
(Result already added to docs/autoconfig.md.)

Update AbstractRepositoryConfigurationSourceSupport to use the newly
introduced RepositoryConfigurationDelegate instead of effectively
reimplementing Spring Data Commons functionality which was prone to
changes in the API (code that wasn't considered to be API in the first
place).

Switch from implementing BeanClassLoaderAware to ResourceLoaderAware
to avoid having to set up a DefaultResourceLoader which should also
improve IDE integration.

Fixes gh-236

Older versions of JBoss AS have a classpath clash with an older
SLF4J (pre 1.6.5), so to prevent an app from blowing up on
startup we defensively catch a NoSuchMethodError.

Fixes gh-339

Locate PropertySourcesLoaders using SpringFactoriesLoader and refactor
the interface to expose file extensions and support 'profiles' within
documents.

Rework ConfigFileApplicationListener for consistent profile loading.
Profiles are now loaded in a consistent order for both profile specific
files, and contained profile documents (i.e. YAML sub-sections).

Also update ConfigFileApplicationListener so that it no longer directly
processes @ProperySource annotations. Instead the standard Spring
ConfigurationClassPostProcessor will insert @PropertySource items with
ConfigFileApplicationListener later re-ordering them.

The SpringApplication can no longer be configured using @ProperySource
annotations, however, application.properties may still be used.

Fixes gh-322

Update ConfigFileApplicationListener so that custom names and custom
locations use consistent ordering. i.e. earlier items take precedence
(same as @ProperySource).

Add "my.property" to `application.properties` in order to test ordering
or property sources.

Also use hamcrest for assertions.

Update javadoc to consistently use the "code" style with <pre> blocks.
Also include the latest spring-javadoc.css formatting file.

Fixes gh-332

Change `EmbeddedWebApplicationContext` to no longer automatically call
`registerShutdownHook()`. Shutdown hooks must now be registered by the
caller (for users of SpringApplication this will happen automatically).

Fixes gh-314

* pull336:
  Now custom SpringApplication class can be used when extending SpringApplicationContextLoader

Previously the core Spring processing of @PropertySource would
resolve placeholders in the location attribute, but the pre-loading
of the property source by Spring Boot didn't do that. Now implemented
using Environment.resolvePlaceholders() (N.B. at a time when the only
Environment entries available are system properties and OS env vars).

E.g.

	@Configuration
	@PropertySource("classpath:/${source.location}.properties")
	protected static class WithPropertySourcePlaceholders {
           ...
	}

When binding a nested map structure, RelaxedDataBinder pre-populates
the target object with default empty maps. Previously, when these
structures overlapped, each step in pre-population process could
potentially overwrite what had come before it. This led to the output
of the pre-population process being incomplete which would lead to a
binding failure.

This commit updates the pre-population process so that it checks to see
if a property's value has already been set by an earlier step in the
process. If it has been set, the existing value is now reused rather
than being overwritten by a new empty map.

Fixes #328