This reverts commit 78432fc7.

Conflicts:
	spring-boot/src/main/java/org/springframework/boot/logging/LoggingApplicationListener.java

Conflicts:
	spring-boot-actuator/src/main/java/org/springframework/boot/actuate/autoconfigure/EndpointMBeanExportProperties.java
	spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/integration/IntegrationAutoConfiguration.java

The property default format is lower case using hyphen. The JMX default
domain property has been harmonized to that format.

Fixes gh-2427

Spring Integration's FileWritingMessageHandler uses a .writing file
while it's in the process of writing a message to disk and then
performs a rename (depending on the OS and filesystem this may or may
not be atommic) to create the .msg file. Prior to this commit the
test was finding the temporary .writing files and examining them. This
could lead to a FileNotFoundException being thrown as the temporary
file was deleted while the test was trying to read its contents.

This commit updates the test to only look for files with a .msg suffix

Fixes gh-2428

This commit updates the documentation to describe the three steps
involved in producing a deployable war file in a single place.

Closes gh-2185

Closes gh-2424

Closes gh-2423

The main change in this commit is to introduce a new BuildHandler
abstraction. A BuildHandler is responsible for producing the metadata
for a build. Two implementations are provided; one for standard builds
and one for incremental builds. This change means that the annotation
processor is no longer concerned with the two different build types
and can use the same logic in each case.

The code for reading and writing metadata files has also been moved
out into a separate class, MetadataStore, to allow it to be easily
utilised from multiple places.

Closes gh-2313

This commit udpdates the metadata annotation processor so that change
data from an incremental build is merged with the metadata from the
previous build.

Closes gh-2321

While `logging.level` is managed in a dedicated way in
`LoggingApplicationListener`, the value of the map are String values
representing the level to apply. The meta-data now exposes that type
instead of raw `java.lang.Object`

Closes gh-2388

Closes gh-2416

This commit adds support for configuring the XA DataSource and
ConnectionFactory pools created by Atomikos and Bitronix via the
environment. The property prefixes vary depending on the transaction
manager that’s in use. They are:

Bitronix:
 - spring.jta.bitronix.datasource
 - spring.jta.bitronix.connectionfactory

Atomikos:
 - spring.jta.atomikos.datasource
 - spring.jta.atomikos.connectionfactory

The configuration processor has been updated to ignore
javax.jms.XAConnectionFactory and javax.sql.XADataSource as neither of
these types can be created via property binding.

Closes gh-2027

Closes gh-2415
See gh-1920

Fixes gh-2410

Fixes gh-2355

Document the need to use a different JTA 1.2 API jar and Tomcat 7 or
Jetty 8 if you’re running on Java 6.

Closes gh-2347

See gh-2396

Closes gh-2396

This commit adds support for configuring Log4j 2 with YAML. It also
improves the existing support for configuring Log4j 2 with JSON.

Previously, Log4J2LoggingSystem returned a hard-coded list of standard
config locations that includes both JSON and XML file suffixes. Log4j 
2’s support for JSON configuration files requires Jackson’s ObjectMapper
to be on the classpath so, in its absence, the standard config locations
were incorrect.

This commit updates Log4J2LoggingSystem to return an array of standard
config locations based on what’s on the classpath. It also updates the
documentation to describe the additional dependencies that are required
to enable YAML or JSON-based configuration.

Closes gh-2239

Closes gh-2394

At the time of writing WAS only supports JPA 2.0 which means that
Hibernate 4.2 is the latest version that can be used. SpringJtaPlatform
is Hibernate 4.3-specific as JtaPlatform’s package changed between
Hibernate 4.2 and 4.3. This means that SpringJtaPlatform can’t be used
on current versions of WAS. Futhermore, SpringJtaPlatform won’t work on
WAS even if we could use Hibernate 4.3 as WAS doesn’t make its
TransactionManager available to application code (it’s considered too
dangerous for general consumption) and SpringJtaPlatform
requires a TransactionManager.

This commit updates HibernateJpaAutoConfiguration to always treat WAS as
a special case and configure Hibernate with one of its WAS-specific
JtaPlatform implementations. 

Closes gh-2326

By default, when building a project's jar its runtime dependencies
are not taken into account as they are not needed to successfully
compile the code that will be packaged in the jar. A side-effect of
this was that, if a project that was being repackaged had a runtime
dependency on another project, then the repackaged jar would not
include the jar of the project on which it has the runtime dependency
as the jar had not been built.

This commit updates Boot's repackage task to have a dependency on the
jar task of any project dependencies in the runtime configuration
thereby ensuring that those dependencies' jars will have been built
before the repackaging occurs.

Fixes gh-2344

Running the invoker plugin with multiple threads against an empty
Maven cache results in strange build failures where Maven claims that
it cannot find a jar or pom file for an artifact that it should be
able to find. It would appear that Maven is unable to cope with
concurrent writes to its cache.

This commit removes the usage of multiple threads that was introduced
in 4e907f19.

Fixes gh-2389

This test covers the code path that caused gh-2361 and also checks that,
when an additional metadata file is found, it’s correctly merged with
the other metadata.

Closes gh-2361

When running in Eclipse, by default Gradle builds its output into a
folder named bin. This commit update the annotation processor to remove
the failure assumption that the output will always be located beneath
a folder named classes.

Closes gh-2369
See gh-2361