So far, one has to set the "fork" value to both the start and stop
goals. Since they have the same name, sharing them in a global
configuration element does the trick. However, the plugin also supports
auto-detection of the fork value according to other parameters:
typically if an agent or jvm arguments are set, forking will be
automatically enabled. This is a problem since the stop goal is not aware
of that.

This commit transmits the value in a property attached to the
`MavenProject`. That way, the stop goal can retrieve that value and
apply the same defaults. This has the side effect that specifying the
fork value isn't necessary anymore.

Closes gh-6747

Closes gh-6764

Closes gh-6559

Previously, BeanTypeRegistry did not correctly determine the type
that would be created by a factory bean if that factory bean was
returned from a bean method with arguments on a configuration class
found via component scanning.

The key difference is that bean definitions for bean methods on
configuration classes found via component scanning use ASM-based
metadata rather than reflection-based metadata. The ASM-based method
data does not provide direct access to the Method that will create the
bean. In this case, BeanTypeRegistry was falling back to looking for
a method with the matching name and no arguments. Therefore, if
the bean method had any arguments it would fail to find the method
and would, therefore, be unable to determine the type of bean
produced by the factory bean.

This commit updates BeanTypeRegistry to use logic that is very similar
to Spring Framework's ConstructorResolver's
resolveFactoryMethodIfPossible method to locate the method that will
produce the factory bean. It looks for a single method with
the required name with any number of arguments. If it finds multiple
methods with the required name and different arguments it returns
null, just as ConstructorResolver does.

Closes gh-6755

* pr/6746:
  Polish contribution
  Detect Neo4j bolt driver

Closes gh-6746

Closes gh-6690

Due to the layout format change in 1.4, Spring Framework is no longer
able to compute a default persistence unit root URL. If a Spring Boot 1.4
application has JPA but does not have any entity, the application started
from a fat jar now fails with a quite cryptic exception.

This commit introduces `ApplicationInfo` as a general replacement for
the `ApplicationArguments` and `Banner` singleton beans that
`SpringApplication` registers on startup. `ApplicationInfo` also defines
the detected "main" `Class` that can be used to compute a last resort
URL that makes sense.

If such bean is available, `EntityManagerFactoryBuilder` now sets the
default persistence unit root location, preventing Spring Framework to
attempt to resolve an unknown location. Note that in our case the
persistence unit root location is actually useless: given the way the
persistence unit is created, nothing actually uses it but Hibernate, as a
compliant JPA provider, has to make sure this setting is set to a valid
URL nevertheless.

Closes gh-6635

Hikari can configure both an underlying Driver or DataSource. Spring Boot
only supports the former so any attempt to trigger the creation of the
latter will lead to an exception since the auto-configuration has set
driver-specific field.

This commit adds an analyzer that intercepts such faulty scenario and
indicate that users should configure Hikari with an underlying DataSource
themselves.

Closes gh-6568

See gh-6688

Closes gh-6688

This commit changes `FailureAnalyzers` so that the loaded
`FailureAnalyzer` instances are initialized before the context eventually
fails.

Before this commit, the `BeanFactoryAware` callback was processed at a
time where the context has already shutdown. Some implementations need
to access components that are no longer available.

Instead, we now initialize them before the context is refreshed.

Closes gh-6748

Closes gh-6730

Closes gh-6732

Closes gh-6731

Closes gh-6740

Closes gh-6738

This commit fixes the prefix for the WebClient and WebDriver auto-config
so that it complies with the prefix set on `AutoconfigureWebMvc`

Closes gh-6727

Closes gh-6729

* gh-6721:
  Include netty-handler as transient dependency of cassandra-driver-dse

Previously, Spring Data Cassandra excluded Netty from the Cassandra
Driver's dependencies. This was an error that we replicated in
our dependency management. The exclusion has been removed from
Spring Data Cassandra's pom. This commit makes the equivalent update
to our dependency management.

Fixes gh-6616
Closes gh-6721

* pr/6728:
  Polish

Closes gh-6728

Closes gh-6724

Previously, configuring the build-info goal in a pom would result in 
Eclipse reporting an error for the pom as it didn’t know if/when to
execute the build-info goal.

This commit adds lifecycle mapping metadata so that the goal is executed
on incremental builds. This ensures that the contents of the generated
file are kept up-to-date, reflecting the latest build time, etc.

Closes gh-6723

This commit marks the auto-configured `JdbcTemplate` as `Primary`. Spring
session creates its own so we could end up with two in a fully auto
configured context.

Closes gh-6717

Previously, Tomcat’s background processing was only enabled on the
context but access logging was configured on the engine. This means that
the access log valve’s background processing method was never called
and, therefore, that it wasn’t flushed periodically.

This commit moves the enablement of background processing up to the
engine, thereby ensuring that the access log is flushed periodically.
Background processing cascades down the container hierarchy so, after
this change, background processing will still be performed on the
context as well.

Closes gh-6646

Closes gh-6661

* gh-6706:
  Polish “Add constructor to TestRestTemplate that takes a RestTemplateBuilder”
  Add constructor to TestRestTemplate that takes a RestTemplateBuilder

Closes gh-6702

Closes gh-6706
See gh-6702

Closes gh-6701

We make Liquibase aware of our custom Commons Logging-based logger by
adding its package to the Liquibase ServiceLocator’s packages to scan.
Previously, this was happening too late so Liquibase may have already
initialized and cached a particular logger.

This commit moves the registration of the extra package from the
Liquibase auto-configuration to the application listener that customises
Liquibase’s ServiceLocator. This ensures that the package is added
before Liquibase is used. Unfortunately, configuring Liquibase’s
ServiceLocator and its packages to scan causes it to try to perform
some logging, resulting in it caching the wrong type of logger. We
work around this problem by resetting Liquibase’s LogFactory once we’ve
finished setting everything up.

Closes gh-6713