Issue: SPR-16465

(cherry picked from commit 285b01fc)

Issue: SPR-14415

This commit migrates all remaining tests from JUnit 3 to JUnit 4, with
the exception of Spring's legacy JUnit 3.8 based testing framework that
is still in use in the spring-orm module.

Issue: SPR-13514

Issue: SPR-12766

Issue: SPR-12488

Issue: SPR-10994

Issue: SPR-10614

instantiateUsingFactoryMethod avoids NPE and reports argument types in case of explicitArgs and resolved generic arguments as well

Issue: SPR-11517

Issue: SPR-11112

Issue: SPR-11093

Update code to have a consistent number of new-line characters after
import statements.

Use LinkedHashMaps/Sets wherever exposed to users, and code tests defensively in terms of expected Map/Set ordering. Otherwise, there'll be runtime order differences between JDK 7 and JDK 8 due to internal HashMap/Set implementation differences.

Issue: SPR-9639

Prior to this commit many test utility classes and sample beans were
duplicated across projects. This was previously necessary due to the
fact that dependent test sources were not shared during a gradle
build. Since the introduction of the 'test-source-set-dependencies'
gradle plugin this is no longer the case.

This commit attempts to remove as much duplicate code as possible,
co-locating test utilities and beans in the most suitable project.
For example, test beans are now located in the 'spring-beans'
project.

Some of the duplicated code had started to drift apart when
modifications made in one project where not ported to others. All
changes have now been consolidated and when necessary existing tests
have been refactored to account for the differences.

Conflicts:
	spring-beans/src/test/java/org/springframework/beans/factory/ConcurrentBeanFactoryTests.java
	spring-beans/src/test/java/org/springframework/beans/factory/support/BeanFactoryGenericsTests.java
	spring-beans/src/test/java/org/springframework/beans/support/PagedListHolderTests.java

Fix deprecation compiler warnings by refactoring code or applying
@SuppressWarnings("deprecation") annotations. JUnit tests of
internally deprecated classes are now themselves marked as
@Deprecated.

Numerous EasyMock deprecation warnings will remain until the
migration to mockito can be completed.

Issue: SPR-10129

Fix serialization warnings by applying @SuppressWarnings("serial")
when appropriate.

In certain cases and for unknown reasons, a correctly-placed
@SuppressWarnings("serial") annotation will fix the warning at the
javac level (i.e. the Gradle command-line), but will produce an
"unnecessary @SuppressWarnings" warning within Eclipse. In these
cases, a private static final serialVersionUID field has been added
with the default value of 1L.

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

Issue: SPR-10127

Currently, if a factory method is parameterized and the corresponding
variable types are declared on the method itself instead of on the
enclosing class or interface, Spring always predicts the return type to
be Object, even if the return type can be explicitly inferred from the
method signature and supplied arguments (which are available in the bean
definition).

This commit introduces a new resolveParameterizedReturnType() method in
GenericTypeResolver that attempts to infer the concrete type for the
generic return type of a given parameterized method, falling back to the
standard return type if necessary. Furthermore,
AbstractAutowireCapableBeanFactory now delegates to
resolveParameterizedReturnType() when predicting the return type for
factory methods.

resolveParameterizedReturnType() is capable of inferring the concrete
type for return type T for method signatures similar to the following.
Such methods may potentially be static. Also, the formal argument list
for such methods is not limited to a single argument.

 - public <T> T foo(Class<T> clazz)
 - public <T> T foo(Object obj, Class<T> clazz)
 - public <V, T> T foo(V obj, Class<T> clazz)
 - public <T> T foo(T obj)

Issue: SPR-9493

Previously, the <value> subelement of a map <entry> allowed one to
specify the type of a specific map entry value. This patch allows a
value-type attribute as well, such that instead of the following
syntax

    <entry key="x-message-ttl">
        <value type="java.lang.Long">100</value>
    </entry>
    <entry key="x-ha-policy" value="all" />

one can now use the more concise form

    <entry key="x-message-ttl" value="100" value-type="java.lang.Long"/>
    <entry key="x-ha-policy" value="all"/>

The new value-type attribute may be used at the <map> level as well,
indicating that all elements are of the same type.

Appropriate tests have been added exercising value-type at the <map> and
<entry> levels.

Issue: SPR-9249

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