In the process of upgrading the build to use Gradle 2.14, the
setFieldOnLegacyEntityWithSideEffectsInToString() test method in
ReflectionTestUtilsTests began to fail. The reason is that the log
level for ReflectionTestUtils is now DEBUG by default with Gradle 2.14.
The apparent cause is that log4j was present on the test runtime
classpath for the spring-test module with all previous versions of
Gradle (via a transitive optional dependency from another project that
spring-test depends on). Thus the configuration in log4j.properties in
spring-test was previously honored, but with Gradle 2.14 a different
commons logging implementation is picked up.
Thus, in addition to upgrading the build to Gradle 2.14, this commit
introduces an explicit test runtime dependency on log4j in the
spring-test module.
The discovered bug in ReflectionTestUtils regarding DEBUG log level
will be addressed separately.
Issue: SPR-14362
Prior to this commit, the ordering of classpath entries in the
generated Eclipse .classpath files did not align with the intended
dependency management configured in the Gradle build. Specifically,
project dependencies often came before dependencies on third-party
libraries required for the given project, causing the project not to
compile in Eclipse.
This commit fixes this issue by introducing new functionality in the
ide.gradle script that moves all project dependencies to the end of the
generated classpath.
Issue: SPR-11836
- Set the eclipse.jdt source and target compatibility to 1.8 in
ide.gradle.
- Updated the instructions in import-into-eclipse.sh to reflect minimum
requirements for building Spring Framework 4.1 against Java 8 with
Eclipse and STS
Issue: SPR-11831
An initial commit with expanded support for static resource handling:
- Add ResourceResolver strategy for resolving a request to a Resource
along with a few implementations.
- Add PublicResourceUrlProvider to get URLs for client-side use.
- Add ResourceUrlEncodingFilter and
PublicResourceUrlProviderExposingInterceptor along with initial
MVC Java config support.
Issue: SPR-10933
Specifically set the source level in generated eclipse projects to 1.7
rather than 1.8. Allows the current eclipse milestone (4.3 M6) in
combination with JDK 8.0 to be used for Spring 4.0 development.
Previously the maven dependencies were specified in an arbitrary order
which made comparing the poms against other versions difficult.
This commit sorts the dependencies by scope, group id, and then
artifact id.
- Change output folders to /bin/main and /bin/test. This prevents
'gradle clean' from breaking eclipse.
- Update copyright header for new files to '2002-2013'
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
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
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.
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
Juergen Hoeller
Stephane Nicoll
Stephane Maldini
Sam Brannen
Sebastien Deleuze
Stephane Nicoll
Juergen Hoeller
Rossen Stoyanchev
Brian Clozel
Phillip Webb
Rob Winch
Phillip Webb
Chris Beams