find . -type f -name "*.java" -or -name "*.aj" | \
    xargs perl -p -i -e "s/[ \t]*$//g" {} \;

Issue: SPR-10127

Prior to this commit, the Spring TestContext Framework only supported
loading an ApplicationContext in integration tests from either XML or
Java Properties files (since Spring 2.5), and Spring 3.1 introduced
support for loading an ApplicationContext in integration tests from
annotated classes (e.g., @Configuration classes). All of the
ContextLoader implementations used to provide this support load a
GenericApplicationContext. However, a GenericApplicationContext is not
suitable for testing a web application since a web application relies on
an implementation of WebApplicationContext (WAC).

This commit makes it possible to integration test Spring-powered web
applications by adding the following functionality to the Spring
TestContext Framework.

 - Introduced AbstractGenericWebContextLoader and two concrete
   subclasses:
   - XmlWebContextLoader
   - AnnotationConfigWebContextLoader

 - Pulled up prepareContext(context, mergedConfig) from
   AbstractGenericContextLoader into AbstractContextLoader to allow it
   to be shared across web and non-web context loaders.

 - Introduced AnnotationConfigContextLoaderUtils and refactored
   AnnotationConfigContextLoader accordingly. These utils are also used
   by AnnotationConfigWebContextLoader.

 - Introduced a new @WebAppConfiguration annotation to denote that the
   ApplicationContext loaded for a test should be a WAC and to configure
   the base resource path for the root directory of a web application.

 - Introduced WebMergedContextConfiguration which extends
   MergedContextConfiguration with support for a baseResourcePath for
   the root directory of a web application.

 - ContextLoaderUtils.buildMergedContextConfiguration() now builds a
   WebMergedContextConfiguration instead of a standard
   MergedContextConfiguration if @WebAppConfiguration is present on the
   test class.

 - Introduced a configureWebResources() method in
   AbstractGenericWebContextLoader that is responsible for creating a
   MockServletContext with a proper ResourceLoader for the
   resourceBasePath configured in the WebMergedContextConfiguration. The
   resulting mock ServletContext is set in the WAC, and the WAC is
   stored as the Root WAC in the ServletContext.

 - Introduced a WebTestExecutionListener that sets up default thread
   local state via RequestContextHolder before each test method by using
   the MockServletContext already present in the WAC and by creating a
   MockHttpServletRequest, MockHttpServletResponse, and
   ServletWebRequest that is set in the RequestContextHolder. WTEL also
   ensures that the MockHttpServletResponse and ServletWebRequest can be
   injected into the test instance (e.g., via @Autowired) and cleans up
   thread locals after each test method.

 - WebTestExecutionListener is configured as a default
   TestExecutionListener before DependencyInjectionTestExecutionListener

 - Extracted AbstractDelegatingSmartContextLoader from
   DelegatingSmartContextLoader and introduced a new
   WebDelegatingSmartContextLoader.

 - ContextLoaderUtils now selects the default delegating ContextLoader
   class name based on the presence of @WebAppConfiguration on the test
   class.

 - Tests in the spring-test-mvc module no longer use a custom
   ContextLoader to load a WebApplicationContext. Instead, they now
   rely on new core functionality provided in this commit.

Issue: SPR-5243

Updated all Javadoc in the Spring TestContext Framework (TCF) to explain
and refer to 'annotated classes' instead of 'configuration classes'.

Specifically, @ContextConfiguration now explicitly defines what is meant
by 'annotated classes', and various other classes now refer to this
definition. Otherwise, the term 'configuration class' has simply been
replaced with 'annotated class'.

Also deleted cross references to deprecated JUnit 3.8 classes and
formatted Javadoc in general for greater readability.

Issue: SPR-9401

Before this change there were numerous javadoc warnings being reported
while building Spring framework API.

This commit resolves most of the javadoc warnings, reducing the total
number from 265 to 103.

Issue: SPR-9113

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

[SPR-8240] polishing the "Context management and caching" section of the reference manual and related Javadoc.

[SPR-8386][SPR-8387] Refined logging regarding detection of default resource locations and default configuration classes.

- Removed generatesDefaults() and supports() from the SmartContextLoader SPI and modified the DelegatingSmartContextLoader algorithm accordingly.
- DelegatingSmartContextLoader no longer operates on a list of candidate loaders but rather on explicit instances of GenericXmlContextLoader and AnnotationConfigContextLoader.
- Updated Javadoc regarding DelegatingSmartContextLoader as the new default loader.
- Updated and polished Javadoc regarding changes in 3.1.
- Now enforcing @ContextConfiguration's restriction on declaring locations or classes but not both.

[SPR-8387] Introduced supports(MergedContextConfiguration) method in the SmartContextLoader SPI; updated existing loaders accordingly; and fleshed out implementation of and tests for the new DelegatingSmartContextLoader.

[SPR-8386] AbstractContextLoader now adheres to the SmartContextLoader contract by verifying the existence of generated default resource locations.

[SPR-8386] Polishing SmartContextLoader SPI; AnnotationConfigContextLoader now only considers static inner classes annotated with @Configuration as configuration classes.

- introduced processContextConfigurationAttributes() method in SmartContextLoader SPI
- refactored AnnotationConfigContextLoader, AbstractContextLoader, AbstractGenericContextLoader, ContextLoaderUtils, and TestContext implementations to take advantage of the SmartContextLoader SPI, MergedContextConfiguration, and ContextConfigurationAttributes
- deleted ResourceTypeAwareContextLoader
- deleted ContextLoaderUtils.LocationsResolver and implementations
- moved context key generation from TestContext to MergedContextConfiguration

[SPR-7960][SPR-8386] Supporting declarative configuration of bean definition profiles in the TestContext framework:
- TextContext now works with MergedContextConfiguration instead of locations and loader
- TextContext now builds context caching key from MergedContextConfiguration
- Test context caching is now based on locations, classes, active profiles, and context loader
- TextContext now delegates to SmartContextLoader or ContextLoader as appropriate
- AbstractContextLoader now implements SmartContextLoader
- AbstractGenericContextLoader now sets active profiles in the GenericApplicationContext 
- Introduced integration tests for profile support in the TCF for both XML and annotation config

[SPR-6184] Introduced ResourceTypeAwareContextLoader interface and removed dependency on AnnotationConfigContextLoader in TestContext.