Prior to this change, the Gradle API Diff task was failing due to a
missing class (a Guava class) during processing. This might be a
dependency that was previously brought by some other dependency.
This commit adds that dependency as a workaround, and improves the
Gradle API Diff task to only select relevant projects when running the
task (projects using the Java Plugin and the Maven Publish Plugin).
This commit removes JDiff from the Spring Framework build and instead,
adds a Gradle plugin that configure JApiCmp tasks on the framework
modules.
Fixes gh-22942
See gh-23282
This commit moves the compile configuration from the Gradle DSL to a
convention. This configuration is not changing often, and we're using
that opportunity to make the Java source compatibility a project
property so as to easily recent JDKs this on the command line.
See gh-23282
Prior to this commit, the Spring Framework build would be using the
propdeps Gradle plugin to introduce two new configurations to the build:
"optional" and "provided". This would also configure related conventions
for IDEs, adding those configurations to published POMs.
This commit removes the need for this plugin and creates instead a
custom plugin for an "optional" configuration. While the Eclipse IDE
support is still supported, there is no need for specific conventions
for IntelliJ IDEA anymore.
This new plugin does not introduce the "provided" scope, as
"compileOnly" and "testCompileOnly" are here for that.
Also as of this commit, optional/provided dependencies are not published
with the Spring Framework modules POMs annymore.
Generally, these dependencies do not provide actionable information to
the developers reading / tools consuming the published POMs.
Optional/Provided dependencies are **not**:
* dependencies you can add to enable some supported feature
* dependencies versions that you can use to figure out CVEs or bugs
* dependencies that might be missing in existing Spring applications
In the context of Spring Framework, optional dependencies are just
libraries are Spring is compiling against for various technical reasons.
With that in mind, we are not publishing that information anymore.
See gh-23282
This commit moves the existing "test sources" Gradle plugin from Groovy
to Java and updates the "buildSrc" build file to prepare for additional
plugins in the Spring Framework build.
The plugin itself looks, for a given Spring Framework module, at all the
project dependencies for the following scopes: "compile", "testCompile",
"api", "implementation" and "optional" (to be supported by a different
plugin).
See gh-23282
The main `build.gradle` file contains now only the common build
infrastructure; all module-specific build configurations have
been moved to their own build file.
Issue: SPR-15885
This commit merges back the "spring-beans-groovy" module into the main
"spring-beans" one. The build is configured so:
* Java and Groovy sources are jointly compiled
* Kotlin sources are compiled after
With this change, the `MergePlugin` is not used anymore in the project
build and therefore is removed.
The `DetectSplitPackagesPlugin` wasn't applied so it's been removed as
well.
Issue: SPR-15885
A little terminiology first:
* merge.from - a project that contains source that will be merged
into merge.into
* merge.into - a project that contains source code that will have
code from merge.from merged into it.
Previously a module that dependended on merge.into would not see
the merge.from module as a transitive dependency. This worked fine
from a Gradle build because all the code from merge.from is merged
into the merge.into jar. However, in an IDE it did not work because
the IDE does not assemble a jar.
This fix ensures that merge.from modules are automatically added
to the classpath of any module relying on the merge.into project.
Fixes SPR-14650
Spring Framework's build is using a custom MergePlugin in order to merge
a project into another one and share/override configuration and
dependencies.
Prior to this commit, two projects merged into a third one could trigger
dependency conflicts when exporting the project definition into a POM.
When trying to define the scope for a given dependency, those two
projects would compete for this with the same priority, resulting in a
Gradle exception.
One could trigger this issue by running:
./gradlew :spring-orm:install -x javadoc
Because `spring-orm-hibernate4` and `spring-orm-hibernate5` get merged
into `spring-orm` and both define optional/test dependencies to
spring-mvc, etc.
This commit makes sure that two projects, when defining dependency
scopes, don't use the same priority value; the MergePlugin now adds the
index of the current subproject to the priority value. So when two
projects compete for this, the one defined in last will define the
dependency scope.
Issue: SPR-13013
The submitted pull requests for SPR-10572 did not build.
This commit fixes the MergePlugin to create from configurations rather
than the project. It also removes unnecessarily added code that was
commented out.
Issue: SPR-10572
Recently Spring framework build has been updated to use Gradle 1.6.
With the new version some of the Gradle APIs have been deprecated.
These deprecated APIs have been used by Spring build specific Gradle
plugins, which resulted in deprecation warnings in build output.
This patch changes Spring build specific Gradle plugins to use new
Gradle APIs instead of deprecated ones.
Even after this change build still produces warnings about Gradle
deprecated APIs being used. These come from Spring shared Gradle
plugins and other 3rd party Gradle plugins in use, like Gradle
Artifactory Plugin (GAP), which are still not updated to Gradle 1.6.
Related tickets for updating of these plugins to Gradle 1.6 are
GRADLE-53 and GAP-144, and once they get resolved Spring framework
build should further be updated.
Issue: SPR-10572
Update gradle MergePlugin to use the 'project.sourceSets.main.output'
for jar content rather than 'project.jar.source'. This prevents
superfluous MANIFEST.MF files from appearing in the merged jar.
Issue: SPR-10324
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
- 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
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
Prior to this commit, the following compilation error presented itself
when importing buildSrc ('spring-build-src') into Eclipse:
Groovy:missing type for constructor call @ line 36, column 49.
This commit replaces the use of the diamond operator with typical
generics syntax in order to work around the problem. It is assumed that
the underlying problem is to do with the Groovy compiler in use. This
change ensures that any contributor / committer importing
spring-framework into Eclipse has a straightforward experience without
being required to tweak Groovy settings.
If selection of the correct Groovy compilation settings can be made
automatic, then we should of course feel free to use Java 7-style syntax
there in the future.
Note that this was *not* a problem when importing buildSrc into IDEA 12.
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.
Brian Clozel
陈其苗
Sam Brannen
Johnny Lim
Andy Wilkinson
Rob Winch
Juergen Hoeller
Rob Winch
Juergen Hoeller
Sam Brannen
Konstantin Petrukhnov
Rob Winch
Stevo Slavic
Phillip Webb
Chris Beams
Glyn Normington