Generate spring-oxm test classes and bindings

 - Generate castor test classes with genCastor task
 - Generate xmlbeans test classes with genXmlbeans task
 - Generate JAXB2 test classes with genJaxb task
 - Generate JiBX bindings by extending existing compileTestJava task

Test classes are written into their own dedicated output folders and
tied into the spring-oxm classpath using the files(...).builtBy(...)
directive.

Incremental build works as expected across all of these customizations.

`gradle eclipse` and `gradle idea` generate correct .project / .iml
metadata respectively, i.e., these special cases do not cause a problem
in the IDE (as they used to prior to the move to Gradle).
Generate OSGi manifests using bundlor-plugin

 - Apply custom-built Gradle 'bundlor' plugin

   This plugin wraps the existing bundlor ant task. Sources available
   at https://github.com/SpringSource/gradle-plugins.

 - Use existing template.mf files

   The bundlor plugin allows for 'inlining' bundlor templates directly
   within build.gradle using the 'importTemplate' property, but opting
   for now to keep the template.mf files separate.

 - Exclude spring-aspects from bundlor processing

   It appears that the bundlor plugin somehow interferes with iajc
   compilation of aspects, resulting in compiler errors. Bundlor
   has been disabled for this project for the time being.

 - Fail the build on any bundlor warning

   The gradle bundlor plugin defaults to failing the build if there are
   any warnings when processing template.mf files. This helps to ensure
   that template.mf files don't drift too far from actual dependency
   declarations. This behavior can be modified by setting

      bundlor {
          failOnWarnings = false
      }

   in the build script.
Remove EBR dependencies where possible

Only a select few EBR dependencies now remain, because these
dependencies cannot be found elsewhere e.g. atinject-tck, or in the case
of Hibernate 3.3.1.GA, to avoid Gradle classpath confusion with
Hibernate 4.0.x (because they have different artifactIds).

Future efforts will be made to fully eliminate these dependencies in
order to ensure we're decoupled completely from EBR.

Important note: these remaining EBR dependencies do not constitute a
problem when publishing artifacts into Maven Central via
oss.sonatype.org, because they are each 'optional' dependencies. It
appears that OSO's restriction around transitive dependencies being
'self-contained' within Maven Central only applies to mandatory
dependencies (which is a good thing for cases just such as this).

Add explicit /ebr-maven-external entry to repositories, as EBR
dependencies are not available via /libs-release.
Remove spring-build and friends
Remove manually-maintained Maven poms

This is in favor of Gradle-generated poms (a la `gradle install`)
Generate Maven Central-compatible poms

Understanding Gradle pom generation
-------------------------------------------

All spring-* subprojects have had Gradle's 'maven' plugin applied to
them. This means that one can run `gradle install`, and POMs will be
generated according to the metadata in the build.gradle file.

The 'customizePom' routine added by this commit hooks into this
generation process in order to add elements to the pom required for
entry into Maven Central via oss.sonatype.org[1].

This pom generation happens on-the-fly during `gradle install` and
the generated poms exist only in your local .m2 cache. Therefore,
you will not see the poms on the source tree after this command.

Handling optional and provided dependencies
-------------------------------------------

Note particularly the handling of 'optional' and 'provided'
dependencies. Gradle does not have a first class notion for these
concepts, nor are they significant to the actual Gradle build process,
but they are important when publishing POMs for consumption via Maven
Central and other Maven-compatible repositories.

<optional>true</optional> indicates that a dependency need not be
downloaded when resolving artifacts. e.g. spring-context has an
compile-time dependency on cglib, but when a Spring user resolves
spring-context from Maven Central, cglib should *not* automatically
be downloaded at the same time. This is because the core functionality
within spring-context can operate just fine without cglib on the
classpath; it is only if the user chooses explicitly to use certain
functionality, e.g. @Configuration classes, which do require cglib,
that the user must declare an explicit dependency in their own build
script on cglib.

Marking these kinds of dependencies as 'optional' provides a kind of
built in 'documentation' about which version of cglib the user should
declare if in fact he wishes to.

Spring has a great many compile-time dependencies, but in fact very
few mandatory runtime dependencies. Therefore, *most* of Spring's
dependencies are optional.

<scope>provided</scope> is similar to 'optional', in that dependencies
so marked should not be automatically downloaded during dependency
resolution, but indicates rather that they are expected to have been
provided by the user application runtime environment. For example, the
Servlet API is in fact a required runtime dependency for spring-webmvc,
but it is expected that it will be available via the user's servlet
container classpath. Again, it serves here as a kind of 'documentation'
that spring-webmvc does in fact expect the servlet api to be available,
and furthermore which (minimum) version.

This commit adds two closures named 'optional' and 'provided' as well as
two arrays (optionalDeps, providedDeps) for tracking which dependencies
are optional or provided. An optional dependency is declared as follows:

    compile("group:artifact:version", optional)

Here, the optional closure accepts the dependency argument implicitly,
and appends it to the 'optionalDeps' array. Then, during pom generation
(again, the customizePom routine), these arrays are interrogated, and
pom <dependency> elements are updated with <optional>true</optional> or
<scope>provided</scope> as appropriate. Thanks to the Spock framework
for inspiration on this approach[2].

[1] http://bit.ly/wauOqP (Sonatype's central sync requirements)
[2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
Rename modules {org.springframework.*=>spring-*}

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
Remove bundlor support
Add Implementation-Version entry to MANIFEST.MF

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.
Fix and refactor spring-aspects build

 - 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
Mark remaining @Ignored tests with 'TODO SPR-8116'

Each of these tests began failing during the Gradle build porting
process. None seem severe, many are likely due to classpath issues.

In the case of TestNG support, this needs to be added to the Gradle
build in order to execute these tests. See SPR-8116.txt
Remove remaining static Eclipse/IDEA metadata

Eclipse .project, .classpath, and .settings metadata have already been
removed. Now removing Eclipse .psf and formatter XML files from the root
project as well as removing all manually-maintained IDEA .iml and .ipr
files.

This is in favor of using Gradle's own 'eclipse' and 'idea' tasks that
generate this kind of metadata on the fly.

.gitignore has been updated to ignore these files going forward. In any
case, they should not be checked into the source tree! The README.md
file will be updated to explain how to generate these files using gradle
and how to import the projects into your IDE of choice.
Update README and add IDE import helper scripts

 - Update building from source section with Gradle instructions
 - Add import-into-eclipse.sh interactive helper script
 - Add import-into-idea.md with steps and known issues

Note that use of STS Gradle tooling was attempted, but several issues
remain before it can handle the spring-framework build. In the meantime
the instructions laid out in import-into-eclipse provide an error-free
import.
Ignore Gradle-related files and directories

When switching back to 3.1.x from master, ignore renamed directories,
Gradle 'build' dirs, generated IDE metadata, etc.

You may wish to clean these files with

    $ git clean -dfx

Or do a dry-run beforehand with the '-n' flag:

    $ git clean -dfxn
Add <license> section to 3.1.x Maven poms

Issue: SPR-8927
Update Quartz links in reference and Javadoc

Issue: SPR-8915
Merge pull request #22 from cbeams/gradle

This merge migrates the Spring Framework 3.2.x build system to Gradle.

Major changes

 - Remove Ant-based spring-build and related resources
 - Replace with Gradle-based build
 - Remove (and .gitignore) all IDE metadata files
 - Remove hand-maintained Maven poms in favor of generation by Gradle
 - Move integration-tests subproject to root src/test dir
 - Move spring-framework-reference subproject to root src/reference dir
 - Rename org.springframework.* subprojects => spring-*

 See individual messages for the commits included in this merge for
 details on each of these changes.

Documentation

 - https://github.com/SpringSource/spring-framework#building_from_source

 - https://github.com/SpringSource/spring-framework/wiki
   see 'Build and release FAQ' and 'SpringSource repository FAQ'

Issue: SPR-8116
Merge branch '3.1.x'

This is the first merge from 3.1.x => master after the Gradle build
system migration. Notice how files changed under the 3.1.x directory
structure (org.springframework.*) merge seamlessly into the new
directory structure (spring-*).

Certain files had changed under 3.1.x that have since been deleted with
the Gradle build migration, e.g. all pom.xml files had <license>
sections added. These files showed up as a conflict during the merge,
but the resolution is to simply re-remove them and commit as they are
no longer relevant under 3.2.x / master.

Also noteworthy is the .gitignore file. It has been updated under 3.1.x
to ignore files and directories specific to the new Gradle-based
structure. However, this causes conflicts when trying to merge against
master, given that master should *not* ignore this directories. The
resolution in this situation is to simply force the 'master' version of
the file, i.e. when prompted for merge resolution:

    anakata:~/Work/spring-framework/spring-framework[master|MERGING]
    $ git status -sb
    ## master...springsource/master [ahead 24]
    UU .gitignore

    anakata:~/Work/spring-framework/spring-framework[master|MERGING]
    $ git checkout master .gitignore

    anakata:~/Work/spring-framework/spring-framework[master|MERGING]
    $ git commit

It is helpful in situations like this one to enable git's "rerere"
feature beforehand, which records and remembers resolution strategies,
avoiding the need to repeat them in future merges:

    $ git config --global rerere.enabled 1

See:
    http://progit.org/2010/03/08/rerere.html
    http://gitfu.wordpress.com/2008/04/20/git-rerere-rereremember-what-you-did-last-time

Conflicts:
    .gitignore
    .springframework.*/pom.xml
Make jasperreports optional for context-support
SPR-9060 Revise HTTP Session based FlashMapManager implementation.

The "default" FlashMapManager implementation added in 3.1 was invoked
after the redirect, which is too late in cases where the HTTP session
has not been yet been created since as the response is committed.

This change corrects the issue and makes other improvements to the
FlashMapManager implementation such as extracting a base
AbstractFlashMapManager class and making it easier for other
implementations to be added (for example cookie-based).