This commit replaces use of the deprecated Gradle `task` method with
the new `tasks.register` method.
Closes gh-34617
Signed-off-by: Dmitry Sulman <dmitry.sulman@gmail.com>
Since the me.champeau.mrjar stores Java 21 main and test sources in
non-standard locations, and since we can only use a single JDK within
Eclipse, this commit updates `ide.gradle` to remove `java21` classpath
entries in Eclipse projects.
Our recent switch from the `org.unbroken-dome.xjc` plugin to the
`com.github.bjornvester.xjc` plugin resulted in errors when trying to
import Spring Framework projects into the Eclipse IDE.
This commit fixes those issues as follows.
- @wilkinsona revised the XJC configuration in `spring-oxm.gradle` to
avoid the ConcurrentModificationException encountered when running
`./gradlew eclipse`.
- I added a workaround in `ide.gradle` to manually remove lingering
"main" classpath entries for sources generated by XJC.
Co-authored-by: Andy Wilkinson <andy.wilkinson@broadcom.com>
Closes gh-33264
The me.champeau.mrjar Gradle plugin causes non-existent libraries to be
added to the Eclipse classpath, such as:
<classpathentry kind="lib" path="/workspaces/spring-framework/spring-core/build/classes/kotlin/java21">
<attributes>
<attribute name="gradle_used_by_scope" value="java21"/>
<attribute name="test" value="true"/>
</attributes>
</classpathentry>
This results in build errors in Eclipse IDE like the following.
Project 'spring-core' is missing required library:
'/workspaces/spring-framework/spring-core/build/classes/kotlin/java21'
This commit filters those and removes them.
Commit 9a180d1811 introduced Kotlin-based
JMH benchmarks which prevent spring-beans from being imported into the
Eclipse IDE.
This commit ensures that src/jmh/kotlin is imported in Eclipse with the
"test" attribute set.
See gh-24104
Prior to this commit, the Spring Framework projects could not be
imported into Eclipse IDE when using JDK 17 to build the projects.
The primary obstacle is the fact that Eclipse enforces a strict
"no split packages between the unnamed module and a system module" rule
when building with a "modular JDK" (such as JDK 17).
Resources:
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=536928
- https://bugs.openjdk.java.net/browse/JDK-8215739
- http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-December/014077.html
- https://stackoverflow.com/questions/51094274/eclipse-cant-find-xml-related-classes-after-switching-build-path-to-jdk-10/53824670#53824670
Since the bug (JDK-8215739) has not been fixed in OpenJDK, the strict
"no split packages" rule does not apply to the Java compiler used in
Spring Framework's Gradle build or the compiler in IntelliJ IDEA. Hence,
this issue only arrises when building the framework in Eclipse IDE.
This commit addresses this issue in the following affected projects.
- spring-oxm: removal of the dependency on XPP3 which publishes
javax.xml.namespace.QName as part of the JAR. The QName type is
also published by the java.xml JDK 17 system module. To make the
tests pass, we have switched to using the DomDriver instead of the
XppDriver in our XStream tests.
- spring-test: HtmlUnit has a transitive dependency on xml-apis which
publishes several packages also published by java.xml JDK 17 system
module. Thus, we have explicitly excluded the transitive dependency
on xml-apis for our `optional` configuration.
See gh-27407
Since the team no longer needs the ability to treat Eclipse projects as
WTP modules, this commit removes the obsolete custom WTP configuration
for importing projects into Eclipse IDE.
See gh-27407
The migration to Gradle 7.2 resulted in a regression for our Eclipse
IDE support: several projects ended up with recursive classpath entries
in their generated .classpath files which prevent those projects from
being built within Eclipse.
This commit addresses this issue with a solution that may well be a
"hack". Nonetheless, a working hack is better than not being able to
import into Eclipse at all.
See gh-26870
Commit 3eec27a723 introduced a custom resource filter for projects
imported into Eclipse IDE. However, commit 85eb589c2e introduced
generated source files within the Gradle 'build' folder, and the filter
prevents Eclipse from seeing the generated sources, resulting in build
errors within the spring-oxm project in Eclipse.
This commit therefore effectively reverts 3eec27a723 by removing the
resource filter.
See gh-25787
Recently the Spring Framework projects could no longer be imported into
Eclipse IDE without compilation errors in JMH sources.
This commit addresses this issue by applying workarounds for bugs in
Gradle and the JMH plugin for Gradle.
Gradle bug: https://github.com/gradle/gradle/issues/14932
JMH plugin bug: https://github.com/melix/jmh-gradle-plugin/issues/157
The Gradle bug has already been fixed in Gradle 6.8 RC1; however, the
issue for the JMH plugin bug seems not to have been triaged yet.
Closes gh-26140
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
The upgrade to Gradle 4.0 broke the custom Eclipse support in the
Spring Framework build.
This commit includes the following changes which re-enable support for
Eclipse in the build.
- Switched to ProjectDependency(String) constructor
- Updated regular expression that matches against project output
dependencies to include more than one subdirectory between "build"
and "main"|"test".
Issue: SPR-15862
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
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.
- 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
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.
Sam Brannen
Dmitry Sulman
Sam Brannen
Sam Brannen
Juergen Hoeller
Brian Clozel
Spring Operator
Spring Operator
Phillip Webb
Phillip Webb
Rob Winch