Update gradle to generate the following project specific eclipse
settings:
- Java formatting
- Cleanup options
- Warning settings
- Code template with copyright header
- WTP module meta-data
In addition this commit changes the eclipse project .classpath file
to output test and main classes to different folders. This is required
to prevent eclipse WTP from packaging test classes into /WEB-INF/lib
jar files.
Issue: SPR-9518
- Now excluding *TestSuite classes from the JUnit test task.
- Renamed SpringJUnit4SuiteTests to SpringJUnit4TestSuite so that it is
no longer executed in the build.
- Reduced sleep time in various timing related tests.
# By Chris Beams (2) and others
* SPR-9990:
Refactor detect-split-packages Gradle plugin
Replace space indentation with tabs
Rework split package detection code
Example SplitPackageDetectorPlugin
Detect split packages at build time
- Use conventional plugin naming, i.e. "detect-split-packages" instead
of applying plugin based on fully-qualified class name
- Rename "diagnose" => "detect" consistently throughout plugin, task
and method names and generally refactor naming throughout to follow
"detect split packages" phrasing
- Add Javadoc to DetectSplitPackagesPlugin
- Improve error reporting when split packages are detected
Upon detecting one or more split packages, `detectSplitPackages` now
fails idiomatically, throwing a GradleException to signal task failure
(as opposed to the previous approach of using an assert assertion), and
the output reads as follows:
$ gradle detectSplitPackages
[...]
:buildSrc:build UP-TO-DATE
:detectSplitPackages FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':detectSplitPackages'.
> The following split package(s) have been detected:
- org.springframework.beans (split across spring-beans and spring-orm)
- org.springframework.core.env (split across spring-context and spring-core)
- DetectSplitPackagesTask now automatically attaches itself to `check`
task lifecycle if the enclosing project contains a `check` task
- DetectSplitPackagesTask adds itself to the 'Verification' task group,
ensuring that it shows up correctly in `gradle tasks` task listings
- packagesToScan now defaults to all subprojects; users may then
customize this by removing individual subprojects from the collection
Issue: SPR-9990
Prior to this commit, the Gradle build configuration only executed
TestNG-based tests and effectively disabled all JUnit-based tests in the
spring-test module. Furthermore, TestNG-based tests were not properly
reported in Bamboo CI builds.
This commit ensures that both JUnit and TestNG tests are executed in the
Gradle build by defining a new testNG task within the spring-test
configuration. The test task now depends on the new testNG task.
Furthermore, the testNG task makes use of Gradle 1.3's support for
generating test reports for TestNG tests alongside reports for JUnit
tests. The net effect is that all tests are executed and reportedly
properly in Bamboo builds on the CI server.
- Enabled both JUnit and TestNG tests for the spring-test module.
- Corrected bugs in FailingBeforeAndAfterMethodsTests introduced in
commit 3d1b3868fe.
- Deleted the now obsolete SPR-9398.txt file.
Issue: SPR-9398
Update the gradle 'api' task to depend on the 'jar' task of all
subprojects. This intern ensures that the 'asmRepackJar' and
'cglibRepackJar' tasks run which is critical for JavaDoc
generation.
Allow packages to be split across projects which will be merged into a
single JAR file.
Make split package detection a dependency of the 'check' task. This
is idiomatic gradle as well as allowing the 'test' task (another
dependency of 'check') to be executed without split packages being
detected.
Omit the project spring-instructment-tomcat from the check on the basis
of SPR-10150.
Issues: SPR-9990, SPR-10150
Conflicts:
build.gradle
Split packages are a well-known anti-pattern for OSGi and a blocker for
Eclipse Virgo (which prevents split packages being accessed via its
Import-Library construct).
Split packages are also unhelpful with a traditional linear classpath
as a split package name does not uniquely identify the Spring framework
JAR from which it came, thus complicating problem diagnosis and
maintenance.
Juergen Hoeller supports this position in the following comment in
SPR-9990:
>FWIW, I generally find split packages a bad practice, even without
>OSGi in the mix. For the Spring Framework codebase, I consider a
>split-package arrangement a design accident that we want to detect
>in any case - and that we're willing to fix if it happened.
>
>I'm actually equally concerned about the source perspective: After
>all, we want a package to be comprehensible from a single glance
>at the project, not requiring the developer to jump into several
>source modules to understand the overall layout of a package.
Split packages have crept into Spring framework twice in recent months
- see SPR-9811 and SPR-9988. Currently, they are only detected once
the Spring framework has been converted to OSGi bundles and these
bundles have been tested with Eclipse Virgo.
This commit adds a build-time check for split packages to the Spring
framework build.
Issue: SPR-9990
Conflicts:
build.gradle
Remove all direct sourceSets.test.output dependencies and instead rely
on the 'test-source-set-dependencies' plugin.
This commit also updates the api JavaDoc task to ensure that
dependencies are not resolved too early.
Both JUnit- and TestNG-based tests are once again executed in the
spring-test module.
Note that two lines in FailingBeforeAndAfterMethodsTests had to be
commented out. See diff or `git grep 'See SPR-8116'` for details.
Issue: SPR-8116
Swap the following EBR-specific dependencies for their equivalents at
Maven Central:
- atinject-tck
- jaxb
- xmlbeans
Remove the /ebr-maven-external repository from the build script entirely
such that all dependencies are now resolved against a single repository:
http://repo.springsource.org/libs-release
Move code from spring-build-junit into spring-core/src/test along with
several other test utility classes. This commit removes the temporary
spring-build-junit project introduced in commit
b083bbdec7.
Develop a gradle plugin to automatically update testCompile dependencies
to include the test source sets of project dependencies.
Allows the gradle build to more closely mirror the way that tests run
inside eclipse.
Introduce new 'spring-build-junit' subproject containing shared
JUnit utilities and classes to be used by other test cases. This
project is for internal use within the framework, and therefore
creates no artifacts to be published to any repository.
The initial code includes support for JUnit Assumptions that can
be used to determine when a test should run. Tests can be skipped
based on the running JDK version, logging level or based on specific
'groups' that have activated via a Gradle property.
It is intended that sources within the spring-build-junit project be
folded into spring-core/src/test/java, pending some Gradle work that
will facilitate sharing test output across subprojects; therefore this
commit should be seen as a temporary solution.
Issue: SPR-9984
"test" source and target compatibility has been upgraded to 1.7 except
where noted, allowing us to use 1.7 language features such as
diamond-style (<>) generics declarations, automatic resource management
and multi-catch. More importantly, we will be able to upgrade to 1.8
once it is available in order to make use of lambda expressions, etc in
our test cases.
IDE configurations must be relaxed to allow 1.7 across the board, as
neither Eclipse nor IDEA are clever enough to allow for different
language levels across production and test resources. See [1] for a
feature request on that front.
spring-oxm is a special case here, and has been pinned at 1.6
compatibility even for its test sources in order to avoid a class
verification error that JibX throws when encountering 1.7-level
bytecode [2].
Likewise with spring-orm, toplink encounters a similar class
verification error, so has been pinned to 1.6 for the time being.
When we remove the (already deprecated since 3.2) Toplink support
we can restore compatibility to 1.7.
[1]: http://youtrack.jetbrains.com/issue/IDEA-97814
[2]: http://jira.codehaus.org/browse/JIBX-465
Issue: SPR-10129
Enable output for the compiler warnings that have been eliminated so
far. 'rawtypes', 'deprecation', and 'unchecked' remain suppressed until
these warnings can be fully eliminated as well.
Pick up fix for regression in version 0.2.3 that caused project-specific
images, e.g. diagrams not to be copied into the images/ folder, thereby
causing broken image links online and in the PDF.
Previously buildSrc/src/main/groovy was a source folder within Eclipse.
This caused build errors due to missing dependencies for Gradle.
This commit removes buildSrc/src/main/groovy from the source folders
within Eclipse to prevent errors from being displayed.
This change upgrades the spring-framework build to AspectJ 1.7.1 to
ensure compatibility. We remain backward-compatible to at least AJ
1.6.12 (the previous version), and likely back to 1.6.7.
AJ 1.7 allows for weaving Java 7 bytecode, particularly with regard
to invokedynamic instructions, and furthermore makes improvements to
the aspectj language itself to allow users to take advantage of Java 7-
style language features within aspects. See [1] for details.
[1]: http://eclipse.org/aspectj/doc/released/README-170.html
Issue: SPR-10079
- 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
Prior to this change, aggregated javadoc has been written to an 'api'
dir and reference docs into a 'reference' dir. This shorter naming is
desirable, but is not compatible with historical naming under 3.1.x as
defined by the Ant+Ivy Spring Build.
For example, URLs are currently as follows:
http://static.springsource.org/spring-framework/docs/3.1.3.RELEASE/javadoc-apihttp://static.springsource.org/spring-framework/docs/3.1.x/javadoc-apihttp://static.springsource.org/spring-framework/docs/current/javadoc-api
Particularly with regard to the 'current' link, we do not want to
break this url scheme with the shortened 'api' directory naming. Of
course this compatibility can be preserved with symlinks, but this makes
the release process that much more complicated and fragile.
This commit ensures that the naming is 'javadoc-api' and
'spring-framework-reference', consistent with historical convention.
We can always add a symlinking scheme to add the shorter 'api' and
'reference' options after the fact if desired.
Refactor the existing merge-artifacts script to a full Gradle plugin.
The new plugin uses a 'merge' extension in favor of Gradle 'ext'
configuration and can be applied to all projects in a multi-module
build.
Any project that defines a 'merge.into' project will now implicitly
receive a dependency to that project. Furthermore other projects
with a dependency on 'merge.into' will receive a direct project
link within the IDE. For example: 'spring-webmvc-tiles3'
is merged into 'spring-webmvc' and 'spring-test-mvc' depends
on 'spring-webmvc'. Within the IDE 'spring-test-mvc' will show
dependencies to both 'spring-webmvc' and 'spring-webmvc-tiles'.
Issue: SPR-10042
Replace existing 'optional' and 'provided' Spring specific build
extensions with a new Gradle propdeps-plugin. Optional and Provided
dependencies are now defined use dependency configurations.
The new plugin does not currently support the notion of optional
runtime dependencies. All optional dependencies are implicitly
part of the 'compile' scope. This is an intentional design decision
that aims to keep both the plugin and the build simple. Since optional
dependencies are non-transitive this restriction should not cause
any real problems for existing users. The only existing dependency
affected is 'commons-io' in the 'spring-beans' project, however, this
was an optional compile scope dependency in the previous Spring 3.1
release.
Both provided and optional dependencies are no longer exported from
generated eclipse .classpath files. This fixes several tests that
would previously fail when running within eclipse. The servlet-api
specific elements of ide.gradle are also no longer required.
Issue: SPR-9656, SPR-10070
Upgrade to the latest stable release of log4j. The previous 'jms'
and 'jmx' exclusions are not longer required since these have now
been marked as optional dependencies in the upstream POM.
Update all Gradle files to use a consistent style when specifying
dependencies. All dependencies are now specified using parentheses,
for example:
scope("group:artifat:version")
or scope(project(":projectname"))
tiles-core-3 brings in a dependency on jcl-overl-slf4 which causes
an slf4j delegation loop as explained at [1] when tests run inside
Eclipse. Other modules that depend on tiles-core like
(tiles-servlet, tiles-jsp) have also had the exclusion added since
they seem to bring it in as well.
[1] http://www.slf4j.org/codes.html#jclDelegationLoop
Prevously the FrameworkServlet created a new ServletRequestAttributes
instance for every request, unless the RequestContextHolder already
contained an instance whose type is not ServletRequestAttributes.
The main intent was that if RequestContextHolder contains a
PortletRequestAttributes, it should be left in place.
This change does an "instanceof" check against the request in
RequestContextHolder instead of an "equals" check on the type.
It still leaves PortletRequestAttributes in place but also allows
the previous request to be any sub-class of ServletRequestAttributes.
Issue: SPR-10025
This commit upgrades the compile dependency on JUnit in the spring-test
module as well as the global test dependency on JUnit for the entire
test suite to 4.11 GA.
In addition, the spring-test module now depends on junit:junit instead
of junit:junit-dep since, as of JUnit 4.11, the "junit" Maven artifact
no longer inlines hamcrest-core.
Issue: SPR-10044
Replace the gradle dependency on aspectjrt with aspectjweaver since
aspectjrt is a subset of aspectjweaver and the full jar is required
by Spring. SPR-8896 fixed the original code issue, this change
just relates to the generated maven pom.
Issue: SPR-10072
Upgrade to docbook-reference-plugin v0.2.2 and remove custom xsl
styles in favor of plugin defaults. Modify some docbook source
files to work with newer style.
- Defined global slf4jVersion as '1.6.1' in the Gradle build.
- Replaced dependencies on slf4j-log4j12 with slf4j-jcl where possible;
however, spring-test-mvc still depends on jcl-over-slf4j and
slf4j-log4j12 (see SPR-10070).
- Reenabled HibernateSessionFlushingTests.
- Verified that the following tests pass in the Gradle build and within
Eclipse:
- HibernateSessionFlushingTests
- HibernateTransactionManagerTests (Hibernate 3)
- HibernateTransactionManagerTests (Hibernate 4)
- RequestResponseBodyMethodProcessorTests
Issue: SPR-9421, SPR-10066
The previous commit by Juergen Hoeller upgraded spring-orm's Hibernate 3
dependency to 3.3.2.GA, and this commit removes the now unnecessary
dependency on org.hibernate:hibernate-cglib-repack:2.1_3.
Issue: SPR-10066
This commit ensures that EasyMock version 2.5.2 is used consistently
across the test suite. This applies to both the easymock and
easymockclassextension artifacts. Using the same version for both of
these artifacts helps to better align us for a future upgrade to
EasyMock 3.0 since the Class Extension artifact is deprecated in 3.x
releases of the library.
Issue: SPR-10069
The tiles-request-servlet-wildcard contained only one class that is an
implementation of the tiles-request ServletApplicationContext using a
Spring ApplicationContext to look up resources. It makes sense for this
class to be part of the Spring Tiles 3 integration.
Issue: SPR-10054
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.
# By Rob Winch
# Via Rob Winch
* gradle-1116:
Make GRADLE-1116 workaround more generic
# By Rob Winch
* spring-test-mvc-classpath:
Fix spring-test-mvc Eclipse classpath
Previously the workaround for GRADLE-1116 only worked for the
merge-dist.gradle projects
Now the workaround is more generic and fixes errors that have since
been introduced when performing a fresh import into Eclipse.
Previously reflection was required when interacting with Hibernate 4 in
order to support both Hibernate 3 and Hibernate 4 since there were
non-passive changes in the APIs. Now that the Spring build uses Gradle
it is trivial to support multiple Hibernate versions.
This commit removes the reflection usage in orm.hibernate4.* by
creating a spring-orm-hibernate4 module that uses
gradle/merge-artifacts.gradle to build a single artifact but keep
distinct classpaths.
Issue: SPR-10039
This change upgrade the framework to consume the newly-published
docbook-reference-plugin version 0.2.1 containing a maximum width
for the HTML reference guide.
This change upgrade the framework to consume the newly-published
docbook-reference-plugin version 0.2.0, which includes among other
improvements a revamped CSS approach designed to look as similar
as possible to the way markdown files are rendered by GitHub.
See associated commit [1] at SpringSource's gradle-plugins repo for
further details.
Issue: SPR-10036
[1]: b209c350ed
In the course of this enhancement, the "cache.ehcache" and "cache.jcache" packages moved from spring-context to the spring-context-support module, expecting further transaction-related functionality. Also aligns with the presence of Spring's Quartz support in the spring-context-support module, since Quartz and EHCache are sort of sister projects at Terracotta now.
Issue: SPR-9966
The new jdiff task generates a report of API differences between the
current version (i.e. the value of `version` in gradle.properties) and
any older version of the framework, as specified by -DOLD_VERSION at
the command line, or defaulting to `previousVersion` in
gradle.properties.
Running the command requires a separate clone directory pinned to the
desired old version, as specified by -DOLD_VERSION_ROOT at the command
line. This creates challenges from a build automation perspective,
largely because Gradle doesn't (yet) have APIs for working with Git.
This task may be further automated and included in nightly CI runs, but
in the meantime, a number of reports back to 3.1.3.RELEASE have been
generated manually and uploaded to [1], where one can now find the
following entries in the directory listing:
- 3.1.3.RELEASE_to_3.2.0.RC1
- 3.2.0.M1_to_3.2.0.M2
- 3.2.0.M2_to_3.2.0.RC1
- 3.2.0.RC1_to_3.2.0.BUILD-SNAPSHOT
Ideally, the final entry there would be kept up-to-date on a daily
basis - again we may revisit doing so in the future. Going forward,
reports will be generated and uploaded manually on an as needed basis
and as part of the release process.
The goal of these reports are as follows:
- to ease the process of ensuring backward compatibility
- to aid in code reviews, particularly when reviewing large pull
requests
- to ease the process of creating migration guides for project
maintainers, i.e. to help us remember what's changed
- to allow ambitious end-users to discover what's been changing at the
API level without without needing to wait for detailed "what's new in
version X" and/or migration guide documentation
See documentation in jdiff.gradle for usage details.
Note that the jdiff-1.1.1 distribution as downloaded from [2] has been
added wholesale to the source tree under gradle/jdiff instead of
uploading JDiff jars to repo.springsource.org as we would normally do.
This is due to some unfortunate limitations in the implementation of the
jdiff ant task that require a phisical JDIFF_HOME directory. Checking in
the jars and various resources represents the simplest and most
pragmatic solution to this problem, though ambitious contributors are
free to do what's necessary to arrive at a more elegant arrangement.
[1]: http://static.springframework.org/spring-framework/docs
[2]: http://sourceforge.net/projects/javadiff/files/latest/download
Issue: SPR-9957
Tiles 3 has modified packages and classes as well as additional
dependencies, notably "tiles-request-api", which is a request/response
abstraction independent of Servlet and JSP APIs.
In order to have both Tiles 2 and Tiles 3 integrations, the source for
the Tiles 3 integration is in a separate project spring-webmvc-tiles3.
The build process merges the compiled Tiles 3 integration classes into
the spring-webmvc module so in effect it contains both the Tiles 2 and
the Tiles 3 integrations.
This change originated as a pull request at spring-framework-issues:
https://github.com/SpringSource/spring-framework-issues/pull/30
And was additionally updated:
1f64be4aa5
Issue: SPR-8825
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
Prior to this change, zip archives were named
spring-${version}-${classifier}.zip
e.g.:
- spring-3.2.0.RC1-dist.zip
- spring-3.2.0.RC1-docs.zip
- spring-3.2.0.RC1-schema.zip
This commit updates the Gradle build script to ensure that the fully-
qualified 'spring-framework' name is used consistently, such that names
follow the pattern
spring-framework-${version}-${classifier}.zip
This includes the naming of the root-level directory within the -dist
zip.
Issue: SPR-9954
JRuby includes a copy of joda classes with the same package names.
This commit changes the order of the loaded jars to load the original
joda classes first.
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
This setting was causing failures in the CI build, and was not present
prior to the recent updates to gradle wrapper generation.
This commit also simplifies the gradle wrapper customizations by placing
the logic in a doLast block within the original 'wrapper' task, as
to creating a second wrapper task and extending from the first.
- Upgrade to 0.1.6 snapshot of docbook plugin
- Fully qualify PDF artifact name as 'spring-framework-reference.pdf'
instead of former 'spring-reference.pdf'
Issue: SPR-9598
This commit adds the spring-test-mvc project [1] to the Spring
Framework as part of the spring-test module.
The sources are added as a root-level project called "spring-test-mvc"
instead of under "spring-test" because the new sources need to be
compiled with Servlet 3 while the current "spring-test" sources require
Servlet 2.5 and the Eclipse IDE does not support having different
classpaths for the same project.
The Gradle build produces a single spring-test jar that contains
sources from both "spring-test" and "spring-test-mvc". This merge is
made possible through merge-dist.gradle as follows:
- jar tasks of the "from" project execute tasks of the "to" project
- "to" project is added to the classpath of the "from" project
- "to" project pom is updated with entries from the "from" project
For further details see documentation in merge-dist.gradle.
Special thanks to everyone who contributed to the initial development
of the Spring MVC Test framework:
Arjen Poutsma <poutsma@mac.com>
Craig Walls <cwalls@vmware.com>
Frans Flippo <fransflippo@utopia.orange11.nl>
Harry Lascelles <harry@firstbanco.com>
Irfan <mail.urfi@gmail.com>
Jörg Rathlev <joerg.rathlev@s24.com>
Keesun Baik <whiteship2000@gmail.com>
Keesun Baik <whiteship@epril.com>
Matthew Reid <matthew.reid@nakedwines.com>
Nils-Helge Garli Hegvik <Nils-Helge.Hegvik@telenor.com>
Rob Winch <rwinch@vmware.com>
Scott Frederick <sfrederick@vmware.com>
Sven Filatov <sven.filatov@gmail.com>
Thomas Bruyelle <thomas.bruyelle@gmail.com>
youngm <youngm@gmail.com>
[1]: https://github.com/SpringSource/spring-test-mvc
Issue: SPR-9859, SPR-7951
Class#getDeclaredMembers returns arbitrary results under JDK7. This
results in non-deterministic execution of JUnit test methods, often
revealing unintended dependencies between methods that rely on a
specific order to succeed.
JUnit 4.11 contains support for predictable test ordering [1], but at
the time of this commit, JUnit 4.11 has not yet been released.
Therefore we are testing against a snapshot version [2], which has been
uploaded to repo.springsource.org [3] for easy access. Note that this
artifact may be removed when JUnit 4.11 goes GA.
- Care has been taken to ensure that spring-test's compile-time
dependency on JUnit remains at 4.10. This means that the spring-test
pom.xml will continue to have an optional <dependency> on JUnit
4.10, instead of the 4.11 snapshot.
- For reasons not fully understood, the upgrade to the 4.11 snapshot
of junit-dep caused NoSuchMethodErrors around certain Hamcrest
types, particularly CoreMatchers and Matchers. import statements
have been updated accordingly throughout affected test cases.
- Runtime errors also occurred around uses of JUnit @Rule and
ExpectedException. These have been reverted to use simpler
mechanisms like @Test(expected) in the meantime.
- Some test methods with order-based dependencies on one another have
been renamed in order to fall in line with JUnit 4.11's new method
ordering (as opposed to actually fixing the inter-test
dependencies). In other areas, the fix was as simple as adding a
tearDown method and cleaning up state.
- For no apparent reason, the timeout in AspectJAutoProxyCreatorTests'
testAspectsAndAdvisorNotAppliedToPrototypeIsFastEnough method begins
to be exceeded. Prior to this commit the timeout value was 3000 ms;
on the CI server under Linux/JDK6 and JDK7, the test begins taking
anywhere from 3500-5500 ms with this commit. It is presumed that
this is an incidental artifact of the upgrade to JUnit 4.11. In any
case, there are no changes to src/main in this commit, so this
should not actually represent a performance risk for Spring
Framework users. The timeout has been increased to 6000 ms to
accommodate this situation.
[1]: https://github.com/KentBeck/junit/pull/293
[2]: https://github.com/downloads/KentBeck/junit/junit-dep-4.11-SNAPSHOT-20120805-1225.jar
[3]: https://repo.springsource.org/simple/ext-release-local/junit/junit-dep/4.11.20120805.1225
Issue: SPR-9783
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
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
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
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
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
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
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
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.
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
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.
- 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.
- 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).
Each spring-* subproject now has sourcesJar and javadocJar tasks
- Ignore subproject overview.html files for now (not all have one)
- Ensure @author attribution occurs
- Javadoc 'header' is project description
spring-asm is a special case
- source jar is created, but empty (to comply with entry rules for
Maven Central)
- add package-info.java explaining the nature of spring-asm
this is nice, because it shows up in the public API docs now.
- add SpringAsmInfo in the org.springframework.asm package as a
placeholder allowing the generation of javadocs (see link to bug)
- add explicit 'repackageAsm' Gradle task allowing for easy testing
and merging of jar containing bundlor manifest as well as jar
containing repackaged ASM classes.
- Add 'api' gradle task to generate project-wide API Javadoc
results in <root>/build/api
- Add docsZip task including api and reference documentation
suitable for publication to
http://static.springframework.org/docs/spring-framework
- Add schemaZip task including all spring-* XSD files
suitable for publication to http://static.springframework.org/schema
- Add distZip task to include all libs, docs and schema
- filter src/dist/*.txt for ${copyright} and ${version}
- copy legal (notice, license) dynamically into individual jar files
- copy legal and readme files into root of distribution zip
- Refactor location of 'wrapper' task
Each of the zip tasks (docsZip, schemaZip, distZip) have been added to
the 'archives' configuration, meaning that (a) they will be built
automatically with `gradle build` and (b) will be published
automatically to artifactory when using the Artifactory Gradle plugin
and/or Artifactory Bamboo integration.
Prior to this change, license.txt and notice.txt files were duplicated
across every subproject in their respective src/main/resources/META-INF
directories.
This commit centralizes these files under the root project at src/dist,
along with the changelog and readme files. The definition of the 'jar'
task has been been extended to include the license and notice files in
module jars as they are created.
The directory is named src/dist because these files are all related to
distribution - the readme is different than the one you see at the root
of the source tree - the intended audience is for users who download
the spring-framework distribution zip. A task to create that
distribution zip will be added in subsequent commits.
The docbook-gradle-plugin has been custom-developed specifically to
handle Spring projects. It is highly opinionated, and not terribly
configurable in its current form. Sources and documentation are
available via the 'gradle-plugins' github repository at
https://github.com/cbeams/gradle-plugins
Note that this repository may soon move locations to the SpringSource
GitHub organization, in which case the url will be
https://github.com/SpringSource/gradle-plugins
In any case, the build plans for these plugins can be found at
https://build.springsource.org/browse/GRADLEPLUGINS
This commit eliminates the 'integration-tests' subproject in favor of
managing these sources under the root project's own 'src' directory.
This helps to avoid special-case handling for integration-tests in the
Gradle build, e.g. avoiding publication of jars to Artifactory /
Maven Central.
It is also semantically more correct. This is not a Spring Framework
subproject so much as it is a collection of integration tests that
span functionality across many subprojects. In this way, it makes
sense to place them directly under the root project.
Issue: SPR-8116
- Use recent Gradle 1.0-milestone-8 snapshot
- Add initial cut of build.gradle able to compile/test all modules
- Update .gitignore
- Generate Gradle wrapper scripts
- Remove all Eclipse metadata files
- Temporarily @Ignore tests that do not pass under Gradle
Phillip Webb
Sam Brannen
Chris Beams
Glyn Normington
Rob Winch
Juergen Hoeller
Rossen Stoyanchev
Fredrik Sundberg
Stevo Slavic
Kris De Volder