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

Issue: SPR-10127

In particular, avoiding synchronized Sets and Maps wherever possible (preferring a ConcurrentHashMap even instead of a synchronized Set) and specifying appropriate ConcurrentHashMap initial capacities (even if we end up choosing 16).

 - 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

This commit adds Javadoc documentation for the WebApplicationContext
testing support that was recently introduced in the Spring TestContext
Framework.

Issue: SPR-9864

Prior to this commit, executing an SQL script with JdbcTestUtils would
fail if a statement in the script contained a line comment within the
statement.

This commit ensures that standard SQL comments (i.e., any text beginning
with two hyphens and extending to the end of the line) are properly
omitted from the statement before executing it.

In addition, multiple adjacent whitespace characters within a statement
but outside a literal are now collapsed into a single space.

Issue: SPR-9982

This commit relocates recently introduced web artifacts in the
TestContext framework to the ~.test.context.web package and renames some
classes for consistency with the existing code base.

 - introduced package-info.java in the web package.

 - ServletTestExecutionListener now extends
   AbstractTestExecutionListener instead of implementing
   TestExecutionListener.

 - relocated AbstractGenericWebContextLoader,
   AnnotationConfigWebContextLoader, XmlWebContextLoader, and
   WebDelegatingSmartContextLoader to the web package.

 - renamed XmlWebContextLoader to GenericXmlWebContextLoader for
   consistency with GenericXmlContextLoader.

 - changed the visibility of AbstractDelegatingSmartContextLoader and
   AnnotationConfigContextLoaderUtils to public.

Issue: SPR-10067

This commit fixes recently introduced formatting errors in the Javadoc
of TransactionalTestExecutionListener.

Issue: SPR-9962

The change removes the use of concrete Matcher implementations and thus
the dependency on hamcrest-lib leaving hamcrest-core as the only
(optional) hamcrest dependency.

Issue: SPR-9961

1) removed the hamcrest-all dependency requirement and replaced it with
the more focused hamcrest-library dependency

2) added MatcherAssertionErrors as a replacement of
org.hamcrest.MatcherAssert, which in hamcrest 1.1 is only available
through the hamcrest-all dependency (and not in hamcrest-core nor in
the hamcrest embedded in JUnit 4.4 through 4.8)

3) changed the required hamcrest version from 1.1 to 1.3 and made sure
the spring-test-mvc project does not rely on newer hamcrest
functionality without checking if it is available first

Applications that already depend on older versions of hamcrest
(in particular 1.1) via hamcrest-library, hamcrest-all or as part of
junit 4.4 through 4.8 should not be disrupted if they add spring-test
but may wish to exclude the hamcrest-library transitive dependency
from spring-test in order to avoid extra jars in the classpath

Applications that depend on hamcrest 1.3 should not have to do anything

Issue: SPR-9940

Code introduced in conjunction with SPR-5243 introduced package cycles
between the ~.test.context and ~.test.context.web packages. This was
caused by the fact that ContextLoaderUtils worked directly with the
@WebAppConfiguration and WebMergedContextConfiguration types.

To address this, the following methods have been introduced in
ContextLoaderUtils. These methods use reflection to circumvent hard
dependencies on the @WebAppConfiguration and
WebMergedContextConfiguration types.

 - loadWebAppConfigurationClass()
 - buildWebMergedContextConfiguration()

Issue: SPR-9924

Prior to this commit, the following two methods in ContextLoaderUtils
contained almost identical loops for traversing the test class
hierarchy:

 - resolveContextLoaderClass(Class<?>, String)
 - resolveContextConfigurationAttributes(Class<?>)

With this commit, resolveContextLoaderClass() no longer traverses the
class hierarchy. Instead, it now works directly with the resolved list
of ContextConfigurationAttributes, thereby removing code duplication.

Issue: SPR-9918

Code introduced in conjunction with SPR-5243 introduced package cycles
between the ~.test.context.web and ~.test.context.support packages. This
was caused by the fact that ServletTestExecutionListener extended
AbstractTestExecutionListener.

To address this, ServletTestExecutionListener now implements
TestExecutionListener directly.

Issue: SPR-9924

Prior to this commit, utility methods in JdbcTestUtils interpreted SQL
comments as separate statements, resulting in an exception when such a
script is executed.

This commit addresses this issue by introducing a
readScript(lineNumberReader, String) method that accepts a comment
prefix. Comment lines are therefore no longer returned in the parsed
script. Furthermore, the existing readScript(lineNumberReader) method
now delegates to this new readScript() method, supplying "--" as the
default comment prefix.

Issue: SPR-9593

Renamed WebTestExecutionListener to ServletTestExecutionListener.

ModelAndViewAssert now uses assertion methods in the newly
introduced AssertionErrors class.

Issue: SPR-9864

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

Issue: SPR-9664

Starting with Spring 3.1 applications can specify
contextInitializerClasses via context-param and init-param in web.xml;
however, there is currently no way to have such initializers invoked in
integration testing scenarios without writing a custom
SmartContextLoader. For comprehensive integration testing it should
therefore be possible to re-use ApplicationContextInitializers in the
Spring TestContext Framework as well.

This commit makes this possible at the @ContextConfiguration level by
allowing an array of ACI types to be specified, and the out-of-the-box
SmartContextLoader implementations invoke the declared initializers at
the appropriate time.

 - Added initializers and inheritInitializers attributes to
   @ContextConfiguration.

 - Introduced support for ApplicationContextInitializers in
   ContextConfigurationAttributes, MergedContextConfiguration, and
   ContextLoaderUtils.

 - MergedContextConfiguration stores context initializer classes as a
   Set and incorporates them into the implementations of hashCode() and
   equals() for proper context caching.

 - ApplicationContextInitializers are invoked in the new
   prepareContext(GenericApplicationContext, MergedContextConfiguration)
   method in AbstractGenericContextLoader, and ordering declared via the
   Ordered interface and @order annotation is honored.

 - Updated DelegatingSmartContextLoader to support initializers.
   Specifically, a test class may optionally declare neither XML
   configuration files nor annotated classes and instead declare only
   application context initializers. In such cases, an attempt will
   still be made to detect defaults, but their absence will not result
   an an exception.

 - Documented support for application context initializers in Javadoc
   and in the testing chapter of the reference manual.

Issue: SPR-9011

ReflectionTestUtils.setField() implicitly calls toString() on the target
object when arguments for a call to Assert.notNull() are built. This can
have undesirable side effects, for example if the toString() invocation
results in a thrown exception or access to an external system (e.g., a
database).

This commit addresses this issue by inlining the Assert.notNull() code,
thereby avoiding accidental invocation of toString() on a non-null
target.

Issue: SPR-9571

The default set of TestExecutionListeners is sufficient in most
integration testing scenarios; however, the TestContextManager
nonetheless logs an INFO message if the @TestExecutionListeners
annotation is not present on an integration test class.

In order to avoid flooding the logs with messages about the absence of
@TestExecutionListeners, this commit reduces the log level for such
messages from INFO to DEBUG.

Issue: SPR-8645

Recently new utility methods were added to JdbcTestUtils, and a
JdbcTemplate was introduced in abstract transactional base classes in
the TestContext framework. This presents an easy opportunity to make
these new utility methods available as convenience methods in the base
test classes.

This commit introduces new countRowsInTableWhere() and dropTables()
convenience methods in the abstract transactional base classes in the
TestContext framework. These new methods internally delegate to methods
of the same names in JdbcTestUtils.

Issue: SPR-9665

Since Spring 2.5, the abstract transactional base classes in the
TestContext framework have defined and delegated to a protected
SimpleJdbcTemplate instance variable; however, SimpleJdbcTemplate has
deprecated since Spring 3.1. Consequently, subclasses of
AbstractTransactionalJUnit4SpringContextTests and
AbstractTransactionalTestNGSpringContextTests that use this instance
variable suffer from seemingly unnecessary deprecation warnings.

This commit addresses this issue by introducing a protected JdbcTemplate
instance variable in abstract transactional base classes to replace the
use of the existing SimpleJdbcTemplate. Furthermore, the existing
simpleJdbcTemplate instance variable has been deprecated, and utility
methods in the affected base classes now delegate to JdbcTestUtils
instead of the now deprecated SimpleJdbcTestUtils.

Issue: SPR-8990

Several static utility methods in SimpleJdbcTestUtils accept an instance
of SimpleJdbcTemplate as an argument; however, SimpleJdbcTemplate has
been deprecated since Spring 3.1 in favor of simply using JdbcTemplate
which now also supports Java 5 language constructs such as var-args.
Consequently, use of such methods from SimpleJdbcTestUtils results in
deprecation warnings without an equivalent API to migrate to.

This commit addresses this issue by migrating all existing methods in
SimpleJdbcTestUtils to JdbcTestUtils. The migrated methods now accept an
instance of JdbcTemplate as an argument, thereby avoiding the
deprecation warnings but maintaining semantic compatibility with the
functionality previous available in SimpleJdbcTestUtils.

In addition, this commit also introduces two new methods:

 - countRowsInTableWhere(): counts the rows in a given table, using
   a provided `WHERE` clause
 - dropTables(): drops the tables with the specified names

Issue: SPR-9235

Currently the Spring TestContext Framework looks up a
PlatformTransactionManager bean named "transactionManager". The exact
name of the bean can be overridden via @TransactionConfiguration or
@Transactional; however, the bean will always be looked up 'by name'.

The TransactionManagementConfigurer interface that was introduced in
Spring 3.1 provides a programmatic approach to specifying the
PlatformTransactionManager bean to be used for annotation-driven
transaction management, and that bean is not required to be named
"transactionManager". However, as of Spring 3.1.2, using the
TransactionManagementConfigurer on a @Configuration class has no effect
on how the TestContext framework looks up the transaction manager.
Consequently, if an explicit name or qualifier has not been specified,
the bean must be named "transactionManager" in order for a transactional
integration test to work.

This commit addresses this issue by refactoring the
TransactionalTestExecutionListener so that it looks up and delegates to
a single TransactionManagementConfigurer as part of the algorithm for
determining the transaction manager.

Issue: SPR-9604

TransactionalTestExecutionListener currently requires that the
PlatformTransactionManager bean be named "transactionManager" by
default. Otherwise, the bean name can only be overridden via the
transactionManager attribute of @TransactionConfiguration or the value
attribute of @Transactional.

However, if there is only a single PlatformTransactionManager in the
test's ApplicationContext, then the requirement to specify the exact
name of that bean (or to name it exactly "transactionManager") is often
superfluous.

This commit addresses this issue by refactoring the
TransactionalTestExecutionListener so that it is comparable to the
algorithm for determining the transaction manager used in
TransactionAspectSupport for "production" code. Specifically, the TTEL
now uses the following algorithm to retrieve the transaction manager.

 - look up by type and qualifier from @Transactional
 - else, look up by type and explicit name from
   @TransactionConfiguration
 - else, look up single bean by type
 - else, look up by type and default name from @TransactionConfiguration

Issue: SPR-9645

Fixed outdated Javadoc regarding support for 'annotated classes' in
the TestContext Framework.

Commit 096693c4 refactored and
deprecated TransactionAspectUtils, moving its #qualifiedBeanOfType
and related methods into BeanFactoryUtils. This created a package cycle
between beans.factory and beans.factory.annotation due to use of the
beans.factory.annotation.Qualifier annotation in these methods.

This commit breaks the package cycle by introducing
beans.factory.annotation.BeanFactoryAnnotationUtils and moving these
@Qualifier-related methods to it. It is intentionally similar in name
and style to the familiar BeanFactoryUtils class for purposes of
discoverability.

There are no backward-compatibilty concerns associated with this change
as the cycle was introduced, caught and now fixed before a release.

Issue: SPR-6847

TransactionAspectUtils contains a number of methods useful in
retrieving a bean by type+qualifier. These methods are functionally
general-purpose save for the hard coding of PlatformTransactionManager
class literals throughout.

This commit generifies these methods and moves them into
BeanFactoryUtils primarily in anticipation of their use by async method
execution interceptors and aspects when performing lookups for qualified
executor beans e.g. via @Async("qualifier").

The public API of TransactionAspectUtils remains backward compatible;
all methods within have been deprecated, and all calls to those methods
throughout the framework refactored to use the new BeanFactoryUtils
variants instead.

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

Before this change javadoc in two classes had non-UTF-8 encoded
characters. This caused building Spring API to fail in Java 1.7.

Commit fixes this by replacing wrongly encoded characters with their
UTF-8 equivalents.

Issue: SPR-9097

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