Previously we had restored the whitespace for *.aj files in 6888a6f28
to avoid a but in aspectj.
We have updated to the latest version of apsectj and restored the
changes in commit 6888a6f28 which included a significant cleanup of
whitespace.
Issue: SPR-10208
Ensure that merge projects do not downgrade the compile time
dependencies of the projects that they are merged into.
This commit restores the scope of the following dependencies which
were inadvertently changed between Spring 3.2.0 and 3.2.1:
spring-orm
-> spring-tx
-> spring-jdbc
spring-webmvc
-> spring-context
-> spring-web
spring-test
-> spring-webmvc
Issue: SPR-10218
Change 'compile' dependencies to 'provided' for projects that are
merged into other projects. This seems to prevent '-sources' and
'-javadoc' jars from appearing on the classpath which can break
javadoc generation.
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
