Issue: SPR-10130

This reverts commit 45fa5082, reversing
changes made to a312d900.

Issue: SPR-10130

 - Support external Javadoc links using Gradle's javadoc.options.links

 - Fix all other Javadoc warnings, such as typos, references to
   non-existent (or no longer existent) types and members, etc,
   including changes related to the Quartz 2.0 upgrade (SPR-8275) and
   adding the HTTP PATCH method (SPR-7985).

 - Suppress all output for project-level `javadoc` tasks in order to
   hide false-negative warnings about cross-module @see and @link
   references (e.g. spring-core having a @see reference to spring-web).
   Use the `--info` (-i) flag to gradle at any time to see project-level
   javadoc warnings without running the entire `api` task. e.g.
   `gradle :spring-core:javadoc -i`

 - Favor root project level `api` task for detection of legitimate
   Javadoc warnings. There are now zero Javadoc warnings across the
   entirety of spring-framework. Goal: keep it that way.

 - Remove all @link and @see references to types and members that exist
   only in Servlet <= 2.5 and Hibernate <= 4.0, favoring 3.0+ and 4.0+
   respectively. This is necessary because only one version of each of
   these dependencies can be present on the global `api` javadoc task's
   classpath. To that end, the `api` task classpath has now been
   customized to ensure that the Servlet 3 API and Hibernate Core 4 jars
   have precedence.

 - SPR-8896 replaced our dependency on aspectjrt with a dependency on
   aspectjweaver, which is fine from a POM point of view, but causes
   a spurious warning to be emitted from the ant iajc task that it
   "cannot find aspectjrt on the classpath" - even though aspectjweaver
   is perfectly sufficient. In the name of keeping the console quiet, a
   new `rt` configuration has been added, and aspectjrt added as a
   dependency to it. In turn, configurations.rt.asPath is appended to
   the iajc classpath during both compileJava and compileTestJava for
   spring-aspects.

Issue: SPR-10078, SPR-8275, SPR-7985, SPR-8896

Changes introduced in Spring 3.1 for Environment support inadvertently
established a cyclic dependency between the
org.springframework.web.context and
org.springframework.web.context.support packages, specifically through
web.context.ContextLoader's invocation of
web.context.support.WebApplicationContextUtils#initServletPropertySources.

This commit introduces ConfigurableWebEnvironment to break this cyclic
dependency. All web.context.ConfigurableWebApplicationContext types now
return web.context.ConfigurableWebEnvironment from their #getEnvironment
methods; web.context.support.StandardServletEnvironment now implements
ConfigurableWebEnvironment and makes the call to
web.context.support.WebApplicationContextUtils#initServletPropertySources
within its implementation of #initPropertySources. This means that
web.context.ContextLoader now invokes
web.context.ConfigurableWebEnvironment#initPropertySources instead of
web.context.support.WebApplicationContextUtils#initServletPropertySources
and thus the cycle is broken.

Issue: SPR-9439

This renaming more intuitively expresses the relationship between
subprojects and the JAR artifacts they produce.

Tracking history across these renames is possible, but it requires
use of the --follow flag to `git log`, for example

    $ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java

will show history up until the renaming event, where

    $ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java

will show history for all changes to the file, before and after the
renaming.

See http://chrisbeams.com/git-diff-across-renamed-directories

Prior to this change, StandardServletEnvironment evaluated a
"jndiPropertySourceEnabled" flag to determine whether or not to add a
JndiPropertySource.  Following the changes introduced in SPR-8490, there
is now no reason not to enable a JNDI property source by default. This
change eliminates the support for "jndiPropertySourceEnabled" and adds
a JndiPropertySource automatically.

Issue: SPR-8545, SPR-8490

Move JNDI_PROPERTY_SOURCE_ENABLED_FLAG from JndiPropertySource to
StandardServletEnvironment, as this is the only context in which the
constant makes sense.

Issue: SPR-8348

Issue: SPR-8348

Issue: SPR-8348

This new hook in the AbstractEnvironment lifecycle allows for more
explicit and predictable customization of property sources by
subclasses.  See Javadoc and existing implementations for detail.

Issue: SPR-8354

DefaultWebEnvironment automatically adds a JndiPropertySource if
a "jndiPropertySourceEnabled" property is detected in any of the
other other default property sources.

Decomposed Environment interface into PropertySources, PropertyResolver
objects

    Environment interface and implementations are still present, but
    simpler.

    PropertySources container aggregates PropertySource objects;
    PropertyResolver provides search, conversion, placeholder
    replacement. Single implementation for now is
    PropertySourcesPlaceholderResolver

Renamed EnvironmentAwarePropertyPlaceholderConfigurer to
PropertySourcesPlaceholderConfigurer

    <context:property-placeholder/> now registers PSPC by default, else
    PPC if systemPropertiesMode* settings are involved

Refined configuration and behavior of default profiles

    See Environment interface Javadoc for details

Added Portlet implementations of relevant interfaces:

    * DefaultPortletEnvironment
    * PortletConfigPropertySource, PortletContextPropertySource
    * Integrated each appropriately throughout Portlet app contexts

Added protected 'createEnvironment()' method to AbstractApplicationContext

    Subclasses can override at will to supply a custom Environment
    implementation.  In practice throughout the framework, this is how
    Web- and Portlet-related ApplicationContexts override use of the
    DefaultEnvironment and swap in DefaultWebEnvironment or
    DefaultPortletEnvironment as appropriate.

Introduced "stub-and-replace" behavior for Servlet- and Portlet-based
PropertySource implementations

    Allows for early registration and ordering of the stub, then
    replacement with actual backing object at refresh() time.

    Added AbstractApplicationContext.initPropertySources() method to
    support stub-and-replace behavior. Called from within existing
    prepareRefresh() method so as to avoid impact with
    ApplicationContext implementations that copy and modify AAC's
    refresh() method (e.g.: Spring DM).

    Added methods to WebApplicationContextUtils and
    PortletApplicationContextUtils to support stub-and-replace behavior

Added comprehensive Javadoc for all new or modified types and members

Added XSD documentation for all new or modified elements and attributes

    Including nested <beans>, <beans profile="..."/>, and changes for
    certain attributes type from xsd:IDREF to xsd:string

Improved fix for detecting non-file based Resources in
PropertiesLoaderSupport (SPR-7547, SPR-7552)

    Technically unrelated to environment work, but grouped in with
    this changeset for convenience.

Deprecated (removed) context:property-placeholder
'system-properties-mode' attribute from spring-context-3.1.xsd

    Functionality is preserved for those using schemas up to and including
    spring-context-3.0.  For 3.1, system-properties-mode is no longer
    supported as it conflicts with the idea of managing a set of property
    sources within the context's Environment object. See Javadoc in
    PropertyPlaceholderConfigurer, AbstractPropertyPlaceholderConfigurer
    and PropertySourcesPlaceholderConfigurer for details.

Introduced CollectionUtils.toArray(Enumeration<E>, A[])

Work items remaining for 3.1 M2:

    Consider repackaging PropertySource* types; eliminate internal use
    of SystemPropertyUtils and deprecate

    Further work on composition of Environment interface; consider
    repurposing existing PlaceholderResolver interface to obviate need
    for resolve[Required]Placeholder() methods currently in Environment.

    Ensure configurability of placeholder prefix, suffix, and value
    separator when working against an AbstractPropertyResolver

    Add JNDI-based Environment / PropertySource implementatinos

    Consider support for @Profile at the @Bean level

    Provide consistent logging for the entire property resolution
    lifecycle; consider issuing all such messages against a dedicated
    logger with a single category.

    Add reference documentation to cover the featureset.