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.
- 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.
Update source and target compatibility from 1.5 to 1.6, meaning that
@Override is now allowed on implementations of interface methods within
main classes.
Issue: SPR-10130
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"))
Rossen Stoyanchev
Chris Beams
Phillip Webb
Sam Brannen
Glyn Normington
Rob Winch
Juergen Hoeller