Issue: SPR-14201

Issue: SPR-14140

Issue: SPR-13952

Issue: SPR-13402

Consistent java.util.Optional resolution, lenient handling of optional multipart files, correct Servlet 3.0 Part list/array selection

Issue: SPR-13418
Issue: SPR-13849
Issue: SPR-13850
Issue: SPR-13893

Issue: SPR-13654

This split avoids a package tangle (between core and core.annotation) and also allows for selective use of raw annotation exposure versus synthesized annotations, with the latter primarily applicable to web and message handler processing at this point.

Issue: SPR-13153

Issue: SPR-11393

Issue: SPR-11393

Issue: SPR-11393

Issue: SPR-11393

Before this change attributes listed with @SessionAttributes would not
be saved in the session when there was a redirect and the controller
method declared a parameter of type RedirectAttributes.

This change ensures it's the "default" model that is always the one
checked for @SessionAttributes under all circumstances since
RedirectAttributes is really only meant to provide String values to
insert into or append to the the redirect URL.

Issue: SPR-12542

After this change, java.util.Optional is supported with @RequestParam,
@RequestHeader, and @MatrixVariable arguments in Java 8. When Optional
is used the required flag is effectively ignored.

Issue: SPR-11829

Before this change @ModelAttribute methods were not invoked in any
particular order other than ensuring global @ControllerAdvice methods
are called first and local @Controller methods second.

This change introduces a simple algorithm that selects the next
@ModelAttribute method to invoke by making a pass over all methods and
looking for one that has no dependencies (i.e. @ModelAttribute
input arguments) or has all dependencies resolved (i.e. available in
the model). The process is repeated until no more @ModelAttribute
methods remain.

If the next @ModelAttribute method cannot be determined because all
remaining methods have unresolved dependencies, the first available
method is picked anyway just as before, i.e. with required
dependencies created through the default constructor.

Examples in ModelFactoryOrderingTests.

Issue: SPR-6299

Prior to this commit, parts of a multipart HTTP request could be
injected in @RequestPart and @RequestParam annotated arguments, when
using types:
* MultipartFile, Collection<MultiPartFile>
* javax.servlet.Part, Collection<Part>

This commits updates @RequestParam and @RequestPart argument resolvers
and now allows the array versions of those types:
* Part[]
* MultiPartFile[]

Note that the MockHtpServletRequest backing tests for standard
Servlets implementations now uses a MultiValueMap to store parts
(versus a simple hashmap).

Issue: SPR-11353

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

This change adds support for @Header and @Headers annotated method
arguments to spring-messaging. Also supported are arguments of type
MessageHeaders, and MessageHeaderAccessor (including sub-types of
MessageHeaderAccessort as long as they provide a wrap(Message<?>)
static factory method).

This change also renames @MessageBody to @Payload.

Issue: SPR-10985

Issue: SPR-10591

SPR-10402 in Spring Framework 3.2.3 treated empty request parameter
values as missing values, if the empty value was turned into a null
by a PropertyEditor or Converter. This caused the regression.

Issue: SPR-10578, SPR-10402, SPR-10584

If type conversion turns an empty request parameter value (i.e. "") to
null, we should treat it as a missing value. By default the
ConversionService doesn't change empty strings and therefore one must
explicitly convert them to null for example by registering a
StringTrimmerEditor with emptyAsNull=true.

Issue: SPR-10402

Issue: SPR-10126

Issue: SPR-10180

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

Issue: SPR-10129

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

Issue: SPR-10127

Previously when running the tests for spring-web, spring-webmvc,
spring-test-mvc, and spring-orm there were possible collissions in the
classpath due to the fact that each had its own copy of the web.Mock*
classes in it. This causes uncertainty for which class the code was
running against. Furthermore, the maintance of keeping the copies up to
date was tedious.

Now there are two copies of the web.Mock* classes. The ones that exist
in spring-test main sources and a copy that supports servlet 3 within
spring-web test sources. The copy in spring-web test sources has been
moved to a new package to avoid having the classes exist twice on the
classpath within Eclipse.

The ErrorsMethodArgumentResolver expects the preceding @ModelAttribute
in the controller method signature to be the last one added in the
model -- an assumption that can break if a model attribute is added
earlier (e.g. through a @ModelAttribute method) and more attributes
are added as well. This fix ensures when an @ModelAttribute is resolved
as a controller method argument it has the highest index in the model.

Issue: SPR-9378

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