"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.
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
Chris Beams
Phillip Webb
Juergen Hoeller
Rob Winch
Rossen Stoyanchev
Sam Brannen
Fredrik Sundberg