spring-core, spring-aop and spring-context each have compile-time
dependencies on classes in the aspectjweaver jar. Prior to this commit,
only spring-core declared an optional dependency on it; now all three
do.

Issue: SPR-9683

Historically spring-orm has had an optional dependency on spring-web,
primarily in support of OpenSessionInView functionality. This optional
dependency was inadvertently made required when porting the build to
Gradle. This commit simply reintroduces the optional setting.

Issue: SPR-9632

Prior to this change, the repackaged spring-asm and spring-cglib jars
were being included wholesale in the spring-core jar, whereas the
intention was to include the unzipped classfiles.

This change ensures that spring-asm and spring-cglib jars are unzipped
on the fly when creating the spring-core jar.

Issue: SPR-9669

CGLIB 3 has been released in order to depend on ASM 4, which Spring now
depends on internally (see previous commit).

This commit eliminates spring-beans' optional dependency on cglib-nodep
v2.2 and instead repackages net.sf.cglib => org.springframework.cglib
much in the same way we have historically done with ASM.

This change is beneficial to users in several ways:

 - Eliminates the need to manually add CGLIB to the application
   classpath; especially important for the growing number of
   @Configuration class users. Java-based configuration functionality,
   along with proxy-target-class and method injection features now
   work 'out of the box' in Spring 3.2.

 - Eliminates the possibility of conflicts with other libraries that
   may dependend on differing versions of CGLIB, e.g. Hibernate
   3.3.1.ga and its dependency on CGLIB 2.1.3 would easily cause a
   conflict if the application were depending on CGLIB 3 for
   Spring-related purposes.

 - Picks up CGLIB 3's changes to support ASM 4, meaning that CGLIB is
   that much less likely to work well in a Java 7 environment due to
   ASM 4's support for transforming classes with invokedynamic
   bytecode instructions.

On CGLIB and ASM:

  CGLIB's own dependency on ASM is also transformed along the way to
  depend on Spring's repackaged org.springframework.asm, primarily to
  eliminate unnecessary duplication of ASM classfiles in spring-core and
  in the process save around 100K in the final spring-core JAR file size.

  It is coincidental that spring-core and CGLIB currently depend on the
  exact same version of ASM (4.0), but it is also unlikely to change any
  time soon. If this change does occur and versions of ASM drift, then
  the size optimization mentioned above will have to be abandoned. This
  would have no compatibility impact, however, so this is a reasonable
  solution now and for the forseeable future.

On a mysterious NoClassDefFoundError:

  During the upgrade to CGLIB 3.0, Spring test cases began failing due to
  NoClassDefFoundErrors being thrown from CGLIB's DebuggingClassWriter
  regarding its use of asm-util's TraceClassVisitor type. previous
  versions of cglib-nodep, particularly 2.2, did not cause this behavior,
  even though cglib-nodep has never actually repackaged and bundled
  asm-util classes. The reason for these NoClassDefFoundErrors occurring
  now is still not fully understood, but appears to be due to subtle JVM
  bytecode preverification rules. The hypothesis is that due to minor
  changes in DebuggingClassWriter such as additional casts, access to
  instance variables declared in the superclass, and indeed a change in
  the superclass hierarchy, preverification may be kicking in on the
  toByteArray method body, at which point the reference to the missing
  TraceClassVisitor type is noticed and the NCDFE is thrown. For this
  reason, a dummy implementation of TraceClassVisitor has been added to
  spring-core in the org.springframework.asm.util package. This class
  simply ensures that Spring's own tests never result in the NCDFE
  described above, and more importantly that Spring's users never
  encounter the same.

Other changes include:

 - rename package-private Cglib2AopProxy => CglibAopProxy
 - eliminate all 'cglibAvailable' checks, warnings and errors
 - eliminate all 'CGLIB2' language in favor of 'CGLIB'
 - eliminate all mention in reference and java docs of needing to add
   cglib(-nodep) to one's application classpath

Issue: SPR-9669

ASM 4.0 is generally compatibile with Java 7 classfiles, particularly
including 'invokedynamic' instructions. This is important when
considering that Spring's component-scanning support is internally
ASM-based and it is increasingly likely that component classes having
invokedynamic instructions may be encountered and read by ASM.
This upgrade, then, is primarily preventive in nature.

Changes include:

 - upgrade from ASM 2.2.3 to ASM 4.0

 - adapt to ASM API changes as necessary throughout spring-core,
   resulting in no impact to the public Spring API.

 - remove dedicated spring-asm module

 - use new :spring-core:asmRepackJar task to repackage
   org.objectweb.asm => org.springframework.asm as per usual and write
   repackaged classes directly into spring-core jar

The choice to eliminate the spring-asm module altogether and instead
inline the repackaged classes directly into spring-core is first to
eliminate an otherwise unnecessary second jar. spring-core has a
non-optional dependency on spring-asm meaning it is always on the
application classpath. This change simplifies that situation by
consoliding two jars into one. The second reason for this choice is in
anticipation of upgrading CGLIB to version 3 and inlining it into
spring-core as well. See subsequent commit for details.

Issue: SPR-9669

JarJar 1.3 now uses ASM 4 in order to be compatible with Java 7
'invokedynamic' instructions. This is not an immediate concern for
the classes that we use JarJar to repackage and transform, but is a
timely upgrade in anticipation of the subsequent commits in which we
upgrade Spring's own dependency on ASM from 2.2.3 to 4.0 and Spring's
dependency on CGLIB from 2.2 to 3.0 (which in turn depends on ASM 4.0).

See https://code.google.com/p/jarjar/wiki/ChangeLog

Issue: SPR-9669

Issue: SPR-9660

As a result of the refactoring, the AsyncContext dispatch mechanism is
used much more centrally. Effectively every asynchronously processed
request involves one initial (container) thread, a second thread to
produce the handler return value asynchronously, and a third thread
as a result of a dispatch back to the container to resume processing
of the asynchronous resuilt.

Other updates include the addition of a MockAsyncContext and support
of related request method in the test packages of spring-web and
spring-webmvc. Also an upgrade of a Jetty test dependency required
to make tests pass.

Issue: SPR-9433

Previously only **/*.java sources files were included in the sources
jars. This is not ideal for the spring-aspects jar nor does it match
prior versions of the sources jars.

Now **/*.aj files are included in addition to the **/*.java files.

Issue: SPR-9576

The HTTP PATCH method is now supported whereever HTTP methods are used.
Annotated controllers can be mapped to RequestMethod.PATCH.

On the client side the RestTemplate execute(..) and exchange(..)
methods can be used with HttpMethod.PATCH. In terms of HTTP client
libraries, Apache HttpComponents HttpClient version 4.2 or later is
required (see HTTPCLIENT-1191). The JDK HttpURLConnection does not
support the HTTP PATCH method.

Issue: SPR-7985

Introduced ContentNeogtiationStrategy for resolving the requested
media types from an incoming request. The available implementations
are based on path extension, request parameter, 'Accept' header,
and a fixed default content type. The logic for these implementations
is based on equivalent options, previously available only in the
ContentNegotiatingViewResolver.

Also in this commit is ContentNegotiationManager, the central class to
use when configuring content negotiation options. It accepts one or
more ContentNeogtiationStrategy instances and delegates to them.

The ContentNeogiationManager can now be used to configure the
following classes:

- RequestMappingHandlerMappingm
- RequestMappingHandlerAdapter
- ExceptionHandlerExceptionResolver
- ContentNegotiatingViewResolver

Issue: SPR-8410, SPR-8417, SPR-8418,SPR-8416, SPR-8419,SPR-7722

Some Spring Framework users and teams cannot use transitive dependency
management tools like Maven, Gradle and Ivy. For them, a `distZip` task
has been added to allow for creating a Spring Framework distribution
from source that includes all optional and required runtime
dependencies for all modules of the framework.

This 'dist-with-deps' zip is not published to the SpringSource
repository nor to the SpringSource community download page. It is
strictly an optional task introduced as a convenience to the users
mentioned above.

Detailed instructions for building this zip locally have been added to
the wiki and the README has been updated with a link to that new doc.

Issue: SPR-6575

Splits the very large index page with all classes into individual pages
organized by first letter.

Issue: SPR-4984

A recent commit made aopalliance optional for spring-aop, while
continuing to require it for spring-tx. On review, this is probably
overly aggressive, and for convenience aopalliance should remain
required for spring-aop. There are use cases for which aopalliance is
indeed optional, but core functionality such as <aop:scoped-proxy>
should never result in a ClassNotFoundException.

This commit returns the aopalliance dependency for spring-aop to
required status, and also explicitly notes the same dependency in other
modules that compile directly against aopalliance types.

Issue: SPR-9501

Issue: SPR-9494

The junit:junit Maven artifact includes a bundled version of hamcrest
core. For projects that depend on later versions of hamcrest this causes
significant issues in terms of dependency management.

The spring-test module now depends on junit:junit-dep, thus allowing
developers to better manage their test dependencies on a more fine
grained level.

Also tidied up dependency issues regarding hamcrest-core and
hamcrest-all across the build.

Issue: SPR-6966

 - Explicitly specify compile-time dependencies on other spring-*
   modules, primarily for accuracy in pom generation and ensuring
   minimal dependencies for users of spring-aspects.

 - Remove use of p: namespace from annotation-cache-aspectj.xml to
   avoid parser-related test failures under Eclipse (likely due to
   classpath differences between Gradle and Eclipse).

The spring-intstrument jar should have a 'Premain-Class:' manifest
entry in order to enable use as a Java agent. This entry was present in
versions 3.1.1 and earlier, but due to build infrastructure changes
starting in 3.2.x this entry was missed. It is now back in place as
expected.

Issue: SPR-9458

Gradle-generated poms thoroughly tested against 3.1.1 versions, with an
eye toward making as many spring-* dependencies optional as possible.

All spring-* modules now declare a Gradle dependency on any other
spring-* module where there is a direct compile-time usage of the
sources in that module. Previously, dependency declarations were
minimal, letting transitive resolution do most of the work. However,
this creates less than ideal poms and is generally not very
informative.

So for example, spring-jdbc uses spring-core, spring-beans and
spring-tx classes directly. Therefore it has the following declarations:

  compile project(":spring-core")
  compile project(":spring-beans")
  compile project(":spring-tx")

spring-core depends on spring-asm, but spring-jdbc does not use
spring-asm classes directly. Therefore spring-jdbc does not declare a
dependency on spring-asm. Transitive resolution is fine in such a case.

As for optional dependencies, it is a matter of degrees what
constitutes optional. A rule of thumb is whether there are legitimate
and likely use cases in which the module can be used without needing
the dependency. spring-jdbc has only one compile-time dependency on
spring-context classes, and that's in JndiDataSourceLookup. It is
certainly reasonable to imagine using spring-jdbc without JNDI,
therefore the spring-context dependency is declared optional as
follows:

  compile(project(":spring-context"), optional) // for JndiDataSourceLookup

In Spring 3.1 the spring-test Maven artifact did not have a required
dependency on spring-core, but there is practically no part of
spring-test that can be used without spring-core. Most test utilities
that are intended to be stand-alone utilities in fact use utility
classes from spring-core (e.g., ReflectionTestUtils). Even some of the
web mocks/stubs use spring-core (e.g., DelegatingServletInputStream).

In addition, the current Gradle build configuration for the spring-test
module is very simplistic -- in that it does not explicitly list any
optional dependencies such as the Servlet and Portlet APIs -- and it
defines a 'compile' dependency on spring-webmvc-portlet.

The resulting Maven dependencies in the generated POM are therefore not
what a typical consumer of the spring-test artifact would reasonably
expect.

To address these issues, the Gradle build configuration for the
spring-test module now explicitly defines the following 'compile'
dependencies:

 - spring-core
 - spring-webmvc, optional
 - spring-webmvc-portlet, optional
 - junit, optional
 - testng, optional
 - servlet-api, optional
 - jsp-api, optional
 - portlet-api, optional
 - activation, provided

The only required dependency is now spring-core; all other dependencies
are 'optional'.

Issue: SPR-8861

Issue: SPR-8774

Before this change JibxMarshallerTests would fail on Windows with an
error message explaining that JiBX compiler generated classes are not
found on the classpath for binding with name 'binding'. Tests would
execute well on Linux and OS X.

Actual root cause of this bug is found to be in JiBX 1.1.5 release that
is used to build Spring. The binding name can be explicitly specified in
JiBX binding file. If omitted, when generating classes the JiBX compiler
as fall-back mechanism tries to derive the binding name from the binding
file name. That logic had a bug which gets manifested when configured
binding file path has mixed Windows and *nix style file separators, as
in case of JibxMarshallerTests being executed on a Windows platform.

This commit resolves this issue by upgrading Spring's build from JiBX
1.1.5 to 1.2.3, as the bug mentioned was fixed in JiBX 1.2. See JIBX-441
for more details.

Issue: SPR-8360

Issue: SPR-9411

The Spring TestContext Framework (TCF) currently builds against TestNG
5.10. Thus in order to ensure that the TCF builds against the latest
release of TestNG without issues and in order to investigate the
possibility of integrating with newer TestNG features, we are upgrading to
version 6.5.2.

Note, however, that the Gradle build currently does not execute any TestNG
tests; this will be addressed in SPR-9398.

Issue: SPR-8221

Spring currently builds against JUnit 4.9; however, in order to ensure
that the Spring TestContext Framework builds and runs against JUnit 4.10
without issues and in order to investigate the possibility of integrating
with newer JUnit features, we are upgrading to JUnit 4.10.

Issue: SPR-9277

Jackson 2 uses completely new package names and new maven artifact ids.
This change adds Jackson 2 as an optional dependency and also provides
MappingJackson2HttpMessageConverter and MappingJackson2JsonView for use
with the new version.

The MVC namespace and the MVC Java config detect and use
MappingJackson2HttpMessageConverter if Jackson 2 is present.
Otherwise if Jackson 1.x is present,
then MappingJacksonHttpMessageConverter is used.

Issue: SPR-9302

 - Fixes deprecation warnings associated with recent upgrade to Gradle
   1.0-rc1

Previously depending on 1.5.10 in certain locations, which caused
NoClassDefFoundErrors in EhCacheCacheTests and other tests due to
mismatches between slf4j -api and -log4j12 versions.

With the exception of one transitive dependency via Hibernate 3.3.1.GA,
all slf4j dependencies are now pegged at 1.6.1 (and all tests pass).

Before this change, IDE settings generated via import-into-eclipse.sh
created a classpath dependency on slf4j-api version 1.6.1 and
slf4j-log4j12 version 1.5.10. As a result running tests inside the IDE
resulted in a NoSuchMethodException.

build.gradle sets the variable slf4jLog4jVersion to '1.5.10'. However,
the hibernate-validator dependency in spring-context pulls in
slf4j-api version 1.6.1. The change ensures the version specified in
the build script variable is used consistently. Whether it should be
1.5.10 or 1.6.1 is a separate concern.

 - Spring remains compatible against AJ version 1.6.8, but is now
   compiling and testing against 1.6.12

 - Encountered what appears to be an AJ bug introduced in 1.6.10: an
   assertion in org.aspectj.weaver.UnresolvedType causes a false
   negative failure when encountering org.springframework.io.Resource
   arrays, e.g. "[org.springframework.io.Resource@xxx". This problem
   has been reported to the AJ team and in the meantime, the recommended
   workaround is to disable assertions either completely, or at least
   selectively with

       -disableassertions:org.aspectj.weaver.UnresolvedType

Issue: SPR-7989, SPR-9272

 - Fix deprecation warnings about dynamic properties; favor use of
   "extra properties extensions" per [1]

 - Certain such deprecations are still issued due to violations within
   the docbook-reference plugin. These will be fixed in an upcoming
   revision of the plugin, at which point spring-framework will upgrade
   to depend on it and these warnings will be eliminated

[1] http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html

Issue: SPR-9327

 - Rename customized .wrapper to default gradle/wrapper directory for
   out of the box compatibility with STS Gradle tooling

 - Add .settings/gradle directory to capture defaults when using STS
   Gradle tooling to import projects

spring-orm now successfully builds against hibernate-core and
hibernate-entitymanager 4.1.0.Final

Issue: SPR-9082

The build script should work against http anyway; use of https here was
an oversight. Changing it now is in response to the following build
failure experienced by a user on his initial attempt to build from
source (with --info output):

  09:02:09.437 [ERROR] [org.gradle.BuildExceptionReporter] Caused
  by: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
  ...
  Cause: Could not GET
  https://repo.springsource.org/plugins-snapshot/org/springframework/
  build/gradle/docbook-reference-plugin/0.1.2-SNAPSHOT/maven-metadata.xml

The actual cause is unknown at this time, but worth noting that upon
switching the url to http, the following log message was issued:

  Forcing close on abandoned resource: Http GET Resource:
  http://repo.springsource.org/plugins-snapshot/org/springframework/
  build/gradle/docbook-reference-plugin/0.1.2-SNAPSHOT/maven-metadata.xml

Previously, the build script was configured to add ajbuilder to the set
of Eclipse/STS build commands, meaning that both javabuilder and
ajbuilder would be present for spring-aspects. This causes unpredictable
behavior, as these two builders compete with each other. As ajbuilder is
a functional superset of javabuilder, this commit ensures that only the
former is present for spring-aspects' .project file.

Also removed warning language in import-into-eclipse.sh about
spring-aspects failing after adding Git support, as this intermittent
problem was almost certainly an artifact of the situation described
above.

 - Fix compileTestJava issue in which test classes were not being
   compiled or run

 - Use built-in eclipse.project DSL instead of withXml closure
   to add AspectJ nature and builder

 - Rename {aspectJ=>aspects}.gradle and format source

e.g.:

    Implementation-Title: spring-core
    Implementation-Version: 3.2.0.BUILD-SNAPSHOT

Setting these values is good as a general practice, but required in
order to support the functionality in spring-core's SpringVersion class.