root
/
spring-framework
mirror of https://github.com/spring-projects/spring-framework.git
1
0
Fork 0
Code Issues Actions 8 Packages Projects Releases Wiki Activity
spring-framework/build.gradle

714 lines
26 KiB
Groovy
Raw Normal View History

Generate reference docs with docbook-gradle-plugin The docbook-gradle-plugin has been custom-developed specifically to handle Spring projects. It is highly opinionated, and not terribly configurable in its current form. Sources and documentation are available via the 'gradle-plugins' github repository at https://github.com/cbeams/gradle-plugins Note that this repository may soon move locations to the SpringSource GitHub organization, in which case the url will be https://github.com/SpringSource/gradle-plugins In any case, the build plans for these plugins can be found at https://build.springsource.org/browse/GRADLEPLUGINS
2012-01-25 20:10:11 +08:00
buildscript {
repositories {
Upgrade to docbook-reference-plugin 0.1.3
2012-02-23 20:34:47 +08:00
maven { url 'http://repo.springsource.org/plugins-release' }
Generate reference docs with docbook-gradle-plugin The docbook-gradle-plugin has been custom-developed specifically to handle Spring projects. It is highly opinionated, and not terribly configurable in its current form. Sources and documentation are available via the 'gradle-plugins' github repository at https://github.com/cbeams/gradle-plugins Note that this repository may soon move locations to the SpringSource GitHub organization, in which case the url will be https://github.com/SpringSource/gradle-plugins In any case, the build plans for these plugins can be found at https://build.springsource.org/browse/GRADLEPLUGINS
2012-01-25 20:10:11 +08:00
}
dependencies {
Upgrade to docbook-reference-plugin 0.1.5 - Fixes deprecation warnings associated with recent upgrade to Gradle 1.0-rc1
2012-04-21 02:53:45 +08:00
classpath 'org.springframework.build.gradle:docbook-reference-plugin:0.1.5'
Generate reference docs with docbook-gradle-plugin The docbook-gradle-plugin has been custom-developed specifically to handle Spring projects. It is highly opinionated, and not terribly configurable in its current form. Sources and documentation are available via the 'gradle-plugins' github repository at https://github.com/cbeams/gradle-plugins Note that this repository may soon move locations to the SpringSource GitHub organization, in which case the url will be https://github.com/SpringSource/gradle-plugins In any case, the build plans for these plugins can be found at https://build.springsource.org/browse/GRADLEPLUGINS
2012-01-25 20:10:11 +08:00
}
}
Move integration tests => src/test This commit eliminates the 'integration-tests' subproject in favor of managing these sources under the root project's own 'src' directory. This helps to avoid special-case handling for integration-tests in the Gradle build, e.g. avoiding publication of jars to Artifactory / Maven Central. It is also semantically more correct. This is not a Spring Framework subproject so much as it is a collection of integration tests that span functionality across many subprojects. In this way, it makes sense to place them directly under the root project. Issue: SPR-8116
2012-01-15 05:51:26 +08:00
configure(allprojects) {
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'idea'
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
group = 'org.springframework'
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
sourceCompatibility=1.5
targetCompatibility=1.5
Upgrade AspectJ from 1.6.8 to 1.6.12 - Spring remains compatible against AJ version 1.6.8, but is now compiling and testing against 1.6.12 - Encountered what appears to be an AJ bug introduced in 1.6.10: an assertion in org.aspectj.weaver.UnresolvedType causes a false negative failure when encountering org.springframework.io.Resource arrays, e.g. "[org.springframework.io.Resource@xxx". This problem has been reported to the AJ team and in the meantime, the recommended workaround is to disable assertions either completely, or at least selectively with -disableassertions:org.aspectj.weaver.UnresolvedType Issue: SPR-7989, SPR-9272
2012-04-15 00:05:20 +08:00
ext.aspectjVersion = '1.6.12'
Use consistent HSQLDB version in Gradle build
2012-08-03 00:30:08 +08:00
ext.hsqldbVersion='1.8.0.10'
spring-test module now depends on junit:junit-dep The junit:junit Maven artifact includes a bundled version of hamcrest core. For projects that depend on later versions of hamcrest this causes significant issues in terms of dependency management. The spring-test module now depends on junit:junit-dep, thus allowing developers to better manage their test dependencies on a more fine grained level. Also tidied up dependency issues regarding hamcrest-core and hamcrest-all across the build. Issue: SPR-6966
2012-06-10 08:33:46 +08:00
ext.junitVersion = '4.10'
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
[compileJava, compileTestJava]*.options*.compilerArgs = ['-Xlint:none']
sourceSets.test.resources.srcDirs = ['src/test/resources', 'src/test/java']
test.systemProperty("java.awt.headless", "true")
repositories {
Remove EBR dependencies where possible Only a select few EBR dependencies now remain, because these dependencies cannot be found elsewhere e.g. atinject-tck, or in the case of Hibernate 3.3.1.GA, to avoid Gradle classpath confusion with Hibernate 4.0.x (because they have different artifactIds). Future efforts will be made to fully eliminate these dependencies in order to ensure we're decoupled completely from EBR. Important note: these remaining EBR dependencies do not constitute a problem when publishing artifacts into Maven Central via oss.sonatype.org, because they are each 'optional' dependencies. It appears that OSO's restriction around transitive dependencies being 'self-contained' within Maven Central only applies to mandatory dependencies (which is a good thing for cases just such as this). Add explicit /ebr-maven-external entry to repositories, as EBR dependencies are not available via /libs-release.
2012-01-19 01:41:44 +08:00
maven { url "http://repo.springsource.org/libs-release" }
maven { url "http://repo.springsource.org/ebr-maven-external" }
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
dependencies {
spring-test module now depends on junit:junit-dep The junit:junit Maven artifact includes a bundled version of hamcrest core. For projects that depend on later versions of hamcrest this causes significant issues in terms of dependency management. The spring-test module now depends on junit:junit-dep, thus allowing developers to better manage their test dependencies on a more fine grained level. Also tidied up dependency issues regarding hamcrest-core and hamcrest-all across the build. Issue: SPR-6966
2012-06-10 08:33:46 +08:00
testCompile ("junit:junit-dep:${junitVersion}") {
exclude group: 'org.hamcrest', module: 'hamcrest-core'
}
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
testCompile "org.hamcrest:hamcrest-all:1.1"
spring-test module now depends on junit:junit-dep The junit:junit Maven artifact includes a bundled version of hamcrest core. For projects that depend on later versions of hamcrest this causes significant issues in terms of dependency management. The spring-test module now depends on junit:junit-dep, thus allowing developers to better manage their test dependencies on a more fine grained level. Also tidied up dependency issues regarding hamcrest-core and hamcrest-all across the build. Issue: SPR-6966
2012-06-10 08:33:46 +08:00
testCompile "org.easymock:easymock:2.5.1"
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
// servlet-api (2.5) and tomcat-servlet-api (3.0) classpath entries should not be
// exported to dependent projects in Eclipse to avoid false compilation errors due
// to changing APIs across these versions
eclipse.classpath.file.whenMerged { classpath ->
classpath.entries.findAll { entry -> entry.path.contains('servlet-api') }*.exported = false
}
Move integration tests => src/test This commit eliminates the 'integration-tests' subproject in favor of managing these sources under the root project's own 'src' directory. This helps to avoid special-case handling for integration-tests in the Gradle build, e.g. avoiding publication of jars to Artifactory / Maven Central. It is also semantically more correct. This is not a Spring Framework subproject so much as it is a collection of integration tests that span functionality across many subprojects. In this way, it makes sense to place them directly under the root project. Issue: SPR-8116
2012-01-15 05:51:26 +08:00
}
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
configure(subprojects) { subproject ->
apply from: "${rootProject.projectDir}/publish-maven.gradle"
Centralize license, notice, etc in src/dist Prior to this change, license.txt and notice.txt files were duplicated across every subproject in their respective src/main/resources/META-INF directories. This commit centralizes these files under the root project at src/dist, along with the changelog and readme files. The definition of the 'jar' task has been been extended to include the license and notice files in module jars as they are created. The directory is named src/dist because these files are all related to distribution - the readme is different than the one you see at the root of the source tree - the intended audience is for users who download the spring-framework distribution zip. A task to create that distribution zip will be added in subsequent commits.
2012-01-25 23:34:53 +08:00
jar {
Add Implementation-Version entry to MANIFEST.MF e.g.: Implementation-Title: spring-core Implementation-Version: 3.2.0.BUILD-SNAPSHOT Setting these values is good as a general practice, but required in order to support the functionality in spring-core's SpringVersion class.
2012-01-26 02:01:45 +08:00
manifest.attributes['Implementation-Title'] = subproject.name
manifest.attributes['Implementation-Version'] = subproject.version
Centralize license, notice, etc in src/dist Prior to this change, license.txt and notice.txt files were duplicated across every subproject in their respective src/main/resources/META-INF directories. This commit centralizes these files under the root project at src/dist, along with the changelog and readme files. The definition of the 'jar' task has been been extended to include the license and notice files in module jars as they are created. The directory is named src/dist because these files are all related to distribution - the readme is different than the one you see at the root of the source tree - the intended audience is for users who download the spring-framework distribution zip. A task to create that distribution zip will be added in subsequent commits.
2012-01-25 23:34:53 +08:00
from("${rootProject.projectDir}/src/dist") {
include "license.txt"
include "notice.txt"
into "META-INF"
expand(copyright: new Date().format('yyyy'), version: project.version)
}
}
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
Generate -sources and -javadoc jars Each spring-* subproject now has sourcesJar and javadocJar tasks - Ignore subproject overview.html files for now (not all have one) - Ensure @author attribution occurs - Javadoc 'header' is project description spring-asm is a special case - source jar is created, but empty (to comply with entry rules for Maven Central) - add package-info.java explaining the nature of spring-asm this is nice, because it shows up in the public API docs now. - add SpringAsmInfo in the org.springframework.asm package as a placeholder allowing the generation of javadocs (see link to bug) - add explicit 'repackageAsm' Gradle task allowing for easy testing and merging of jar containing bundlor manifest as well as jar containing repackaged ASM classes.
2012-01-16 21:23:31 +08:00
javadoc {
options.memberLevel = org.gradle.external.javadoc.JavadocMemberLevel.PROTECTED
options.author = true
options.header = project.name
//options.overview = "${projectDir}/src/main/java/overview.html"
}
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
task sourcesJar(type: Jar, dependsOn:classes) {
classifier = 'sources'
Include **/*.aj files in *-sources.jar files Previously only **/*.java sources files were included in the sources jars. This is not ideal for the spring-aspects jar nor does it match prior versions of the sources jars. Now **/*.aj files are included in addition to the **/*.java files. Issue: SPR-9576
2012-07-10 08:11:08 +08:00
from sourceSets.main.allJava.srcDirs
include '**/*.java', '**/*.aj'
Generate -sources and -javadoc jars Each spring-* subproject now has sourcesJar and javadocJar tasks - Ignore subproject overview.html files for now (not all have one) - Ensure @author attribution occurs - Javadoc 'header' is project description spring-asm is a special case - source jar is created, but empty (to comply with entry rules for Maven Central) - add package-info.java explaining the nature of spring-asm this is nice, because it shows up in the public API docs now. - add SpringAsmInfo in the org.springframework.asm package as a placeholder allowing the generation of javadocs (see link to bug) - add explicit 'repackageAsm' Gradle task allowing for easy testing and merging of jar containing bundlor manifest as well as jar containing repackaged ASM classes.
2012-01-16 21:23:31 +08:00
}
task javadocJar(type: Jar) {
classifier = 'javadoc'
from javadoc
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
artifacts {
archives sourcesJar
Generate -sources and -javadoc jars Each spring-* subproject now has sourcesJar and javadocJar tasks - Ignore subproject overview.html files for now (not all have one) - Ensure @author attribution occurs - Javadoc 'header' is project description spring-asm is a special case - source jar is created, but empty (to comply with entry rules for Maven Central) - add package-info.java explaining the nature of spring-asm this is nice, because it shows up in the public API docs now. - add SpringAsmInfo in the org.springframework.asm package as a placeholder allowing the generation of javadocs (see link to bug) - add explicit 'repackageAsm' Gradle task allowing for easy testing and merging of jar containing bundlor manifest as well as jar containing repackaged ASM classes.
2012-01-16 21:23:31 +08:00
archives javadocJar
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
}
Remove spring-asm and inline ASM 4 into spring-core ASM 4.0 is generally compatibile with Java 7 classfiles, particularly including 'invokedynamic' instructions. This is important when considering that Spring's component-scanning support is internally ASM-based and it is increasingly likely that component classes having invokedynamic instructions may be encountered and read by ASM. This upgrade, then, is primarily preventive in nature. Changes include: - upgrade from ASM 2.2.3 to ASM 4.0 - adapt to ASM API changes as necessary throughout spring-core, resulting in no impact to the public Spring API. - remove dedicated spring-asm module - use new :spring-core:asmRepackJar task to repackage org.objectweb.asm => org.springframework.asm as per usual and write repackaged classes directly into spring-core jar The choice to eliminate the spring-asm module altogether and instead inline the repackaged classes directly into spring-core is first to eliminate an otherwise unnecessary second jar. spring-core has a non-optional dependency on spring-asm meaning it is always on the application classpath. This change simplifies that situation by consoliding two jars into one. The second reason for this choice is in anticipation of upgrading CGLIB to version 3 and inlining it into spring-core as well. See subsequent commit for details. Issue: SPR-9669
2012-08-07 19:16:00 +08:00
project('spring-core') {
description = 'Spring Core'
def asmVersion = '4.0'
Generate -sources and -javadoc jars Each spring-* subproject now has sourcesJar and javadocJar tasks - Ignore subproject overview.html files for now (not all have one) - Ensure @author attribution occurs - Javadoc 'header' is project description spring-asm is a special case - source jar is created, but empty (to comply with entry rules for Maven Central) - add package-info.java explaining the nature of spring-asm this is nice, because it shows up in the public API docs now. - add SpringAsmInfo in the org.springframework.asm package as a placeholder allowing the generation of javadocs (see link to bug) - add explicit 'repackageAsm' Gradle task allowing for easy testing and merging of jar containing bundlor manifest as well as jar containing repackaged ASM classes.
2012-01-16 21:23:31 +08:00
configurations {
jarjar
Remove spring-asm and inline ASM 4 into spring-core ASM 4.0 is generally compatibile with Java 7 classfiles, particularly including 'invokedynamic' instructions. This is important when considering that Spring's component-scanning support is internally ASM-based and it is increasingly likely that component classes having invokedynamic instructions may be encountered and read by ASM. This upgrade, then, is primarily preventive in nature. Changes include: - upgrade from ASM 2.2.3 to ASM 4.0 - adapt to ASM API changes as necessary throughout spring-core, resulting in no impact to the public Spring API. - remove dedicated spring-asm module - use new :spring-core:asmRepackJar task to repackage org.objectweb.asm => org.springframework.asm as per usual and write repackaged classes directly into spring-core jar The choice to eliminate the spring-asm module altogether and instead inline the repackaged classes directly into spring-core is first to eliminate an otherwise unnecessary second jar. spring-core has a non-optional dependency on spring-asm meaning it is always on the application classpath. This change simplifies that situation by consoliding two jars into one. The second reason for this choice is in anticipation of upgrading CGLIB to version 3 and inlining it into spring-core as well. See subsequent commit for details. Issue: SPR-9669
2012-08-07 19:16:00 +08:00
asm
Generate -sources and -javadoc jars Each spring-* subproject now has sourcesJar and javadocJar tasks - Ignore subproject overview.html files for now (not all have one) - Ensure @author attribution occurs - Javadoc 'header' is project description spring-asm is a special case - source jar is created, but empty (to comply with entry rules for Maven Central) - add package-info.java explaining the nature of spring-asm this is nice, because it shows up in the public API docs now. - add SpringAsmInfo in the org.springframework.asm package as a placeholder allowing the generation of javadocs (see link to bug) - add explicit 'repackageAsm' Gradle task allowing for easy testing and merging of jar containing bundlor manifest as well as jar containing repackaged ASM classes.
2012-01-16 21:23:31 +08:00
}
Remove spring-asm and inline ASM 4 into spring-core ASM 4.0 is generally compatibile with Java 7 classfiles, particularly including 'invokedynamic' instructions. This is important when considering that Spring's component-scanning support is internally ASM-based and it is increasingly likely that component classes having invokedynamic instructions may be encountered and read by ASM. This upgrade, then, is primarily preventive in nature. Changes include: - upgrade from ASM 2.2.3 to ASM 4.0 - adapt to ASM API changes as necessary throughout spring-core, resulting in no impact to the public Spring API. - remove dedicated spring-asm module - use new :spring-core:asmRepackJar task to repackage org.objectweb.asm => org.springframework.asm as per usual and write repackaged classes directly into spring-core jar The choice to eliminate the spring-asm module altogether and instead inline the repackaged classes directly into spring-core is first to eliminate an otherwise unnecessary second jar. spring-core has a non-optional dependency on spring-asm meaning it is always on the application classpath. This change simplifies that situation by consoliding two jars into one. The second reason for this choice is in anticipation of upgrading CGLIB to version 3 and inlining it into spring-core as well. See subsequent commit for details. Issue: SPR-9669
2012-08-07 19:16:00 +08:00
task asmRepackJar(type: Jar) { repackJar ->
repackJar.baseName = "spring-asm-repack"
repackJar.version = asmVersion
Generate -sources and -javadoc jars Each spring-* subproject now has sourcesJar and javadocJar tasks - Ignore subproject overview.html files for now (not all have one) - Ensure @author attribution occurs - Javadoc 'header' is project description spring-asm is a special case - source jar is created, but empty (to comply with entry rules for Maven Central) - add package-info.java explaining the nature of spring-asm this is nice, because it shows up in the public API docs now. - add SpringAsmInfo in the org.springframework.asm package as a placeholder allowing the generation of javadocs (see link to bug) - add explicit 'repackageAsm' Gradle task allowing for easy testing and merging of jar containing bundlor manifest as well as jar containing repackaged ASM classes.
2012-01-16 21:23:31 +08:00
doLast() {
project.ant {
taskdef name: "jarjar", classname: "com.tonicsystems.jarjar.JarJarTask",
classpath: configurations.jarjar.asPath
Remove spring-asm and inline ASM 4 into spring-core ASM 4.0 is generally compatibile with Java 7 classfiles, particularly including 'invokedynamic' instructions. This is important when considering that Spring's component-scanning support is internally ASM-based and it is increasingly likely that component classes having invokedynamic instructions may be encountered and read by ASM. This upgrade, then, is primarily preventive in nature. Changes include: - upgrade from ASM 2.2.3 to ASM 4.0 - adapt to ASM API changes as necessary throughout spring-core, resulting in no impact to the public Spring API. - remove dedicated spring-asm module - use new :spring-core:asmRepackJar task to repackage org.objectweb.asm => org.springframework.asm as per usual and write repackaged classes directly into spring-core jar The choice to eliminate the spring-asm module altogether and instead inline the repackaged classes directly into spring-core is first to eliminate an otherwise unnecessary second jar. spring-core has a non-optional dependency on spring-asm meaning it is always on the application classpath. This change simplifies that situation by consoliding two jars into one. The second reason for this choice is in anticipation of upgrading CGLIB to version 3 and inlining it into spring-core as well. See subsequent commit for details. Issue: SPR-9669
2012-08-07 19:16:00 +08:00
jarjar(destfile: repackJar.archivePath) {
configurations.asm.each { originalJar ->
zipfileset(src: originalJar)
Generate -sources and -javadoc jars Each spring-* subproject now has sourcesJar and javadocJar tasks - Ignore subproject overview.html files for now (not all have one) - Ensure @author attribution occurs - Javadoc 'header' is project description spring-asm is a special case - source jar is created, but empty (to comply with entry rules for Maven Central) - add package-info.java explaining the nature of spring-asm this is nice, because it shows up in the public API docs now. - add SpringAsmInfo in the org.springframework.asm package as a placeholder allowing the generation of javadocs (see link to bug) - add explicit 'repackageAsm' Gradle task allowing for easy testing and merging of jar containing bundlor manifest as well as jar containing repackaged ASM classes.
2012-01-16 21:23:31 +08:00
}
rule(pattern: 'org.objectweb.asm.**', result: 'org.springframework.asm.@1')
}
}
}
}
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
dependencies {
Remove spring-asm and inline ASM 4 into spring-core ASM 4.0 is generally compatibile with Java 7 classfiles, particularly including 'invokedynamic' instructions. This is important when considering that Spring's component-scanning support is internally ASM-based and it is increasingly likely that component classes having invokedynamic instructions may be encountered and read by ASM. This upgrade, then, is primarily preventive in nature. Changes include: - upgrade from ASM 2.2.3 to ASM 4.0 - adapt to ASM API changes as necessary throughout spring-core, resulting in no impact to the public Spring API. - remove dedicated spring-asm module - use new :spring-core:asmRepackJar task to repackage org.objectweb.asm => org.springframework.asm as per usual and write repackaged classes directly into spring-core jar The choice to eliminate the spring-asm module altogether and instead inline the repackaged classes directly into spring-core is first to eliminate an otherwise unnecessary second jar. spring-core has a non-optional dependency on spring-asm meaning it is always on the application classpath. This change simplifies that situation by consoliding two jars into one. The second reason for this choice is in anticipation of upgrading CGLIB to version 3 and inlining it into spring-core as well. See subsequent commit for details. Issue: SPR-9669
2012-08-07 19:16:00 +08:00
asm "org.ow2.asm:asm:${asmVersion}@jar", "org.ow2.asm:asm-commons:${asmVersion}@jar"
jarjar 'com.googlecode.jarjar:jarjar:1.3'
compile files(asmRepackJar)
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
compile "commons-logging:commons-logging:1.1.1"
Upgrade AspectJ from 1.6.8 to 1.6.12 - Spring remains compatible against AJ version 1.6.8, but is now compiling and testing against 1.6.12 - Encountered what appears to be an AJ bug introduced in 1.6.10: an assertion in org.aspectj.weaver.UnresolvedType causes a false negative failure when encountering org.springframework.io.Resource arrays, e.g. "[org.springframework.io.Resource@xxx". This problem has been reported to the AJ team and in the meantime, the recommended workaround is to disable assertions either completely, or at least selectively with -disableassertions:org.aspectj.weaver.UnresolvedType Issue: SPR-7989, SPR-9272
2012-04-15 00:05:20 +08:00
compile("org.aspectj:aspectjweaver:${aspectjVersion}", optional)
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("net.sf.jopt-simple:jopt-simple:3.0") { dep ->
optional dep
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
exclude group: 'org.apache.ant', module: 'ant'
}
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("log4j:log4j:1.2.15") { dep ->
optional dep
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
exclude group: 'javax.mail', module: 'mail'
exclude group: 'javax.jms', module: 'jms'
exclude group: 'com.sun.jdmk', module: 'jmxtools'
exclude group: 'com.sun.jmx', module: 'jmxri'
}
testCompile "xmlunit:xmlunit:1.2"
testCompile "org.codehaus.woodstox:wstx-asl:3.2.7"
}
Remove spring-asm and inline ASM 4 into spring-core ASM 4.0 is generally compatibile with Java 7 classfiles, particularly including 'invokedynamic' instructions. This is important when considering that Spring's component-scanning support is internally ASM-based and it is increasingly likely that component classes having invokedynamic instructions may be encountered and read by ASM. This upgrade, then, is primarily preventive in nature. Changes include: - upgrade from ASM 2.2.3 to ASM 4.0 - adapt to ASM API changes as necessary throughout spring-core, resulting in no impact to the public Spring API. - remove dedicated spring-asm module - use new :spring-core:asmRepackJar task to repackage org.objectweb.asm => org.springframework.asm as per usual and write repackaged classes directly into spring-core jar The choice to eliminate the spring-asm module altogether and instead inline the repackaged classes directly into spring-core is first to eliminate an otherwise unnecessary second jar. spring-core has a non-optional dependency on spring-asm meaning it is always on the application classpath. This change simplifies that situation by consoliding two jars into one. The second reason for this choice is in anticipation of upgrading CGLIB to version 3 and inlining it into spring-core as well. See subsequent commit for details. Issue: SPR-9669
2012-08-07 19:16:00 +08:00
jar {
// inline all repackaged asm classes directly into the spring-core jar
from(asmRepackJar) {
exclude 'META-INF/**'
}
}
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
project('spring-beans') {
description = 'Spring Beans'
dependencies {
compile project(":spring-core")
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("javax.el:el-api:1.0", provided)
compile("javax.inject:javax.inject:1", provided)
compile("cglib:cglib-nodep:2.2", optional)
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
}
project('spring-aop') {
description = 'Spring AOP'
dependencies {
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile project(":spring-core")
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
compile project(":spring-beans")
Require aopalliance dependency for spring-aop A recent commit made aopalliance optional for spring-aop, while continuing to require it for spring-tx. On review, this is probably overly aggressive, and for convenience aopalliance should remain required for spring-aop. There are use cases for which aopalliance is indeed optional, but core functionality such as <aop:scoped-proxy> should never result in a ClassNotFoundException. This commit returns the aopalliance dependency for spring-aop to required status, and also explicitly notes the same dependency in other modules that compile directly against aopalliance types. Issue: SPR-9501
2012-06-13 19:47:47 +08:00
compile("aopalliance:aopalliance:1.0")
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("com.jamonapi:jamon:2.4", optional)
compile("commons-pool:commons-pool:1.5.3", optional)
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
}
project('spring-expression') {
description = 'Spring Expression Language (SpEL)'
dependencies {
compile project(":spring-core")
}
}
project('spring-instrument') {
description = 'Spring Instrument'
dependencies {
compile project(":spring-core")
}
Fix missing spring-instrument jar manifest entry The spring-intstrument jar should have a 'Premain-Class:' manifest entry in order to enable use as a Java agent. This entry was present in versions 3.1.1 and earlier, but due to build infrastructure changes starting in 3.2.x this entry was missed. It is now back in place as expected. Issue: SPR-9458
2012-06-01 15:58:02 +08:00
jar {
manifest.attributes['Premain-Class'] =
'org.springframework.instrument.InstrumentationSavingAgent'
}
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
project('spring-instrument-tomcat') {
description = 'Spring Instrument Tomcat'
dependencies {
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("org.apache.tomcat:catalina:6.0.16", provided)
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
}
project('spring-context') {
description = 'Spring Context'
dependencies {
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile(project(":spring-instrument"), optional)
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
compile project(":spring-aop")
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile project(":spring-beans")
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
compile project(":spring-expression")
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile project(":spring-core")
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("backport-util-concurrent:backport-util-concurrent:3.0", optional)
compile("javax.annotation:jsr250-api:1.0", optional)
compile("javax.ejb:ejb-api:3.0", optional)
compile("javax.inject:javax.inject:1", optional)
compile("org.apache.geronimo.specs:geronimo-jms_1.1_spec:1.1", optional)
compile("org.apache.geronimo.specs:geronimo-jta_1.1_spec:1.1", optional)
compile("javax.persistence:persistence-api:1.0", optional)
compile("javax.validation:validation-api:1.0.0.GA", optional)
compile("javax.xml.ws:jaxws-api:2.1-1") { dep ->
optional dep
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
exclude group: 'javax.jws', module: 'jsr181'
}
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("org.beanshell:bsh:2.0b4", optional)
compile("org.codehaus.groovy:groovy-all:1.6.3", optional)
compile("org.jruby:jruby:1.4.0", optional)
Fix transitive dependency issue with slf4j-api Before this change, IDE settings generated via import-into-eclipse.sh created a classpath dependency on slf4j-api version 1.6.1 and slf4j-log4j12 version 1.5.10. As a result running tests inside the IDE resulted in a NoSuchMethodException. build.gradle sets the variable slf4jLog4jVersion to '1.5.10'. However, the hibernate-validator dependency in spring-context pulls in slf4j-api version 1.6.1. The change ensures the version specified in the build script variable is used consistently. Whether it should be 1.5.10 or 1.6.1 is a separate concern.
2012-03-31 00:42:46 +08:00
compile("org.hibernate:hibernate-validator:4.2.0.Final") { dep ->
optional dep
exclude group: 'org.slf4j', module: 'slf4j-api'
}
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("joda-time:joda-time:1.6", optional)
Add initial support for JCache-compliant providers Issue: SPR-8774
2012-05-28 06:21:33 +08:00
compile("javax.cache:cache-api:0.5", optional)
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("net.sf.ehcache:ehcache-core:2.0.0", optional)
Upgrade slf4j-api and -log4j12 dependencies to 1.6.1 Previously depending on 1.5.10 in certain locations, which caused NoClassDefFoundErrors in EhCacheCacheTests and other tests due to mismatches between slf4j -api and -log4j12 versions. With the exception of one transitive dependency via Hibernate 3.3.1.GA, all slf4j dependencies are now pegged at 1.6.1 (and all tests pass).
2012-04-17 16:51:16 +08:00
compile("org.slf4j:slf4j-api:1.6.1", optional)
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("org.codehaus.jsr166-mirror:jsr166:1.7.0", provided)
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
testCompile "commons-dbcp:commons-dbcp:1.2.2"
Remove EBR dependencies where possible Only a select few EBR dependencies now remain, because these dependencies cannot be found elsewhere e.g. atinject-tck, or in the case of Hibernate 3.3.1.GA, to avoid Gradle classpath confusion with Hibernate 4.0.x (because they have different artifactIds). Future efforts will be made to fully eliminate these dependencies in order to ensure we're decoupled completely from EBR. Important note: these remaining EBR dependencies do not constitute a problem when publishing artifacts into Maven Central via oss.sonatype.org, because they are each 'optional' dependencies. It appears that OSO's restriction around transitive dependencies being 'self-contained' within Maven Central only applies to mandatory dependencies (which is a good thing for cases just such as this). Add explicit /ebr-maven-external entry to repositories, as EBR dependencies are not available via /libs-release.
2012-01-19 01:41:44 +08:00
testCompile("javax.xml:jaxrpc-api:1.1")
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
testCompile("javax.inject:com.springsource.org.atinject.tck:1.0.0")
}
Upgrade AspectJ from 1.6.8 to 1.6.12 - Spring remains compatible against AJ version 1.6.8, but is now compiling and testing against 1.6.12 - Encountered what appears to be an AJ bug introduced in 1.6.10: an assertion in org.aspectj.weaver.UnresolvedType causes a false negative failure when encountering org.springframework.io.Resource arrays, e.g. "[org.springframework.io.Resource@xxx". This problem has been reported to the AJ team and in the meantime, the recommended workaround is to disable assertions either completely, or at least selectively with -disableassertions:org.aspectj.weaver.UnresolvedType Issue: SPR-7989, SPR-9272
2012-04-15 00:05:20 +08:00
test {
jvmArgs = ['-disableassertions:org.aspectj.weaver.UnresolvedType'] // SPR-7989
}
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
project('spring-tx') {
description = 'Spring Transaction'
dependencies {
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile(project(":spring-context"), optional) // for JCA, @EnableTransactionManagement
compile(project(":spring-aop"), optional)
compile project(":spring-beans")
compile project(":spring-core")
Require aopalliance dependency for spring-aop A recent commit made aopalliance optional for spring-aop, while continuing to require it for spring-tx. On review, this is probably overly aggressive, and for convenience aopalliance should remain required for spring-aop. There are use cases for which aopalliance is indeed optional, but core functionality such as <aop:scoped-proxy> should never result in a ClassNotFoundException. This commit returns the aopalliance dependency for spring-aop to required status, and also explicitly notes the same dependency in other modules that compile directly against aopalliance types. Issue: SPR-9501
2012-06-13 19:47:47 +08:00
compile("aopalliance:aopalliance:1.0")
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("com.ibm.websphere:uow:6.0.2.17", provided)
compile("javax.resource:connector-api:1.5", optional)
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile("org.apache.geronimo.specs:geronimo-jta_1.1_spec:1.1", optional)
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
testCompile "org.easymock:easymockclassextension:2.3"
}
}
project('spring-oxm') {
description = 'Spring Object/XML Marshalling'
Generate spring-oxm test classes and bindings - Generate castor test classes with genCastor task - Generate xmlbeans test classes with genXmlbeans task - Generate JAXB2 test classes with genJaxb task - Generate JiBX bindings by extending existing compileTestJava task Test classes are written into their own dedicated output folders and tied into the spring-oxm classpath using the files(...).builtBy(...) directive. Incremental build works as expected across all of these customizations. `gradle eclipse` and `gradle idea` generate correct .project / .iml metadata respectively, i.e., these special cases do not cause a problem in the IDE (as they used to prior to the move to Gradle).
2012-01-18 01:22:24 +08:00
apply from: 'oxm.gradle'
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
dependencies {
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile project(":spring-beans")
compile project(":spring-core")
compile(project(":spring-context"), optional) // for Jaxb2Marshaller
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
compile "commons-lang:commons-lang:2.5"
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("com.thoughtworks.xstream:xstream:1.3.1", optional)
compile("com.sun.xml.bind:jaxb-impl:2.1.7", optional)
Fix JibxMarshallerTests failing on Windows Before this change JibxMarshallerTests would fail on Windows with an error message explaining that JiBX compiler generated classes are not found on the classpath for binding with name 'binding'. Tests would execute well on Linux and OS X. Actual root cause of this bug is found to be in JiBX 1.1.5 release that is used to build Spring. The binding name can be explicitly specified in JiBX binding file. If omitted, when generating classes the JiBX compiler as fall-back mechanism tries to derive the binding name from the binding file name. That logic had a bug which gets manifested when configured binding file path has mixed Windows and *nix style file separators, as in case of JibxMarshallerTests being executed on a Windows platform. This commit resolves this issue by upgrading Spring's build from JiBX 1.1.5 to 1.2.3, as the bug mentioned was fixed in JiBX 1.2. See JIBX-441 for more details. Issue: SPR-8360
2012-03-21 02:14:00 +08:00
compile("org.jibx:jibx-run:1.2.3", optional)
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("org.apache.xmlbeans:xmlbeans:2.4.0", optional)
compile("org.codehaus.castor:castor-xml:1.3.2", optional)
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
testCompile "org.codehaus.jettison:jettison:1.0.1"
testCompile "xmlunit:xmlunit:1.2"
testCompile "xmlpull:xmlpull:1.1.3.4a"
Generate spring-oxm test classes and bindings - Generate castor test classes with genCastor task - Generate xmlbeans test classes with genXmlbeans task - Generate JAXB2 test classes with genJaxb task - Generate JiBX bindings by extending existing compileTestJava task Test classes are written into their own dedicated output folders and tied into the spring-oxm classpath using the files(...).builtBy(...) directive. Incremental build works as expected across all of these customizations. `gradle eclipse` and `gradle idea` generate correct .project / .iml metadata respectively, i.e., these special cases do not cause a problem in the IDE (as they used to prior to the move to Gradle).
2012-01-18 01:22:24 +08:00
testCompile(files(genCastor.classesDir).builtBy(genCastor))
testCompile(files(genJaxb.classesDir).builtBy(genJaxb))
testCompile(files(genXmlbeans.classesDir).builtBy(genXmlbeans))
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
}
project('spring-jms') {
description = 'Spring JMS'
dependencies {
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile project(":spring-core")
compile project(":spring-beans")
compile project(":spring-aop")
compile project(":spring-context")
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
compile project(":spring-tx")
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile(project(":spring-oxm"), optional)
Require aopalliance dependency for spring-aop A recent commit made aopalliance optional for spring-aop, while continuing to require it for spring-tx. On review, this is probably overly aggressive, and for convenience aopalliance should remain required for spring-aop. There are use cases for which aopalliance is indeed optional, but core functionality such as <aop:scoped-proxy> should never result in a ClassNotFoundException. This commit returns the aopalliance dependency for spring-aop to required status, and also explicitly notes the same dependency in other modules that compile directly against aopalliance types. Issue: SPR-9501
2012-06-13 19:47:47 +08:00
compile("aopalliance:aopalliance:1.0")
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("org.codehaus.jackson:jackson-mapper-asl:1.4.2", optional)
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
}
project('spring-jdbc') {
description = 'Spring JDBC'
dependencies {
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile project(":spring-core")
compile project(":spring-beans")
compile(project(":spring-context"), optional) // for JndiDataSourceLookup
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
compile project(":spring-tx")
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("c3p0:c3p0:0.9.1.2", optional)
Use consistent HSQLDB version in Gradle build
2012-08-03 00:30:08 +08:00
compile("hsqldb:hsqldb:${hsqldbVersion}", optional)
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("com.h2database:h2:1.0.71", optional)
compile("org.apache.derby:derby:10.5.3.0_1", optional)
compile("org.apache.derby:derbyclient:10.5.3.0_1", optional)
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile("org.apache.geronimo.specs:geronimo-jta_1.1_spec:1.1", optional)
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
}
project('spring-context-support') {
description = 'Spring Context Support'
dependencies {
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile project(":spring-core")
compile project(":spring-beans")
compile project(":spring-context")
compile(project(":spring-jdbc"), optional) // for Quartz support
compile(project(":spring-tx"), optional) // for Quartz support
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("org.codehaus.fabric3.api:commonj:1.1.0", optional)
compile("opensymphony:quartz:1.6.2", optional)
compile("javax.mail:mail:1.4", optional)
compile("velocity:velocity:1.5", optional)
compile("commons-collections:commons-collections:3.2", optional)
compile("org.freemarker:freemarker:2.3.15", optional)
Make jasperreports optional for context-support
2012-02-01 00:57:18 +08:00
compile("jasperreports:jasperreports:2.0.5") { dep ->
optional dep
transitive = false
}
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("commons-digester:commons-digester:1.8.1", optional)
compile("commons-beanutils:commons-beanutils:1.8.0", optional)
compile("com.lowagie:itext:2.0.8", optional)
Use consistent HSQLDB version in Gradle build
2012-08-03 00:30:08 +08:00
testCompile "hsqldb:hsqldb:${hsqldbVersion}"
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
testCompile("org.apache.poi:poi:3.0.2-FINAL") {
exclude group: 'log4j', module: 'log4j'
}
}
// pick up **/*.types files in src/main
sourceSets.main.resources.srcDirs += 'src/main/java'
}
project('spring-web') {
description = 'Spring Web'
dependencies {
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile project(":spring-core")
compile project(":spring-beans") // for MultiPartFilter
compile project(":spring-aop") // for JaxWsPortProxyFactoryBean
compile project(":spring-context")
compile(project(":spring-oxm"), optional) // for MarshallingHttpMessageConverter
Require aopalliance dependency for spring-aop A recent commit made aopalliance optional for spring-aop, while continuing to require it for spring-tx. On review, this is probably overly aggressive, and for convenience aopalliance should remain required for spring-aop. There are use cases for which aopalliance is indeed optional, but core functionality such as <aop:scoped-proxy> should never result in a ClassNotFoundException. This commit returns the aopalliance dependency for spring-aop to required status, and also explicitly notes the same dependency in other modules that compile directly against aopalliance types. Issue: SPR-9501
2012-06-13 19:47:47 +08:00
compile("aopalliance:aopalliance:1.0")
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("com.caucho:hessian:3.2.1", optional)
compile("rome:rome:1.0", optional)
compile("javax.el:el-api:1.0", optional)
compile("javax.faces:jsf-api:1.2_08", optional)
compile("javax.portlet:portlet-api:2.0", provided)
compile("org.apache.tomcat:tomcat-servlet-api:7.0.8", provided) // servlet-api 3.0
compile("javax.servlet.jsp:jsp-api:2.1", provided)
compile("javax.xml.soap:saaj-api:1.3", provided)
compile("axis:axis:1.4", optional)
compile("commons-fileupload:commons-fileupload:1.2", optional)
runtime("commons-io:commons-io:1.3", optional)
compile("commons-httpclient:commons-httpclient:3.1", optional)
Add support for HTTP PATCH method The HTTP PATCH method is now supported whereever HTTP methods are used. Annotated controllers can be mapped to RequestMethod.PATCH. On the client side the RestTemplate execute(..) and exchange(..) methods can be used with HttpMethod.PATCH. In terms of HTTP client libraries, Apache HttpComponents HttpClient version 4.2 or later is required (see HTTPCLIENT-1191). The JDK HttpURLConnection does not support the HTTP PATCH method. Issue: SPR-7985
2012-06-23 04:47:33 +08:00
compile("org.apache.httpcomponents:httpclient:4.2", optional)
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("org.codehaus.jackson:jackson-mapper-asl:1.4.2", optional)
Add Jackson 2 HttpMessageConverter and View Jackson 2 uses completely new package names and new maven artifact ids. This change adds Jackson 2 as an optional dependency and also provides MappingJackson2HttpMessageConverter and MappingJackson2JsonView for use with the new version. The MVC namespace and the MVC Java config detect and use MappingJackson2HttpMessageConverter if Jackson 2 is present. Otherwise if Jackson 1.x is present, then MappingJacksonHttpMessageConverter is used. Issue: SPR-9302
2012-05-10 01:07:25 +08:00
compile("com.fasterxml.jackson.core:jackson-databind:2.0.1", optional)
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("taglibs:standard:1.1.2", optional)
Refactor Servlet 3 async support As a result of the refactoring, the AsyncContext dispatch mechanism is used much more centrally. Effectively every asynchronously processed request involves one initial (container) thread, a second thread to produce the handler return value asynchronously, and a third thread as a result of a dispatch back to the container to resume processing of the asynchronous resuilt. Other updates include the addition of a MockAsyncContext and support of related request method in the test packages of spring-web and spring-webmvc. Also an upgrade of a Jetty test dependency required to make tests pass. Issue: SPR-9433
2012-07-25 04:00:05 +08:00
compile("org.eclipse.jetty:jetty-servlet:8.1.5.v20120716") { dep ->
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
optional dep
Refactor Servlet 3 async support As a result of the refactoring, the AsyncContext dispatch mechanism is used much more centrally. Effectively every asynchronously processed request involves one initial (container) thread, a second thread to produce the handler return value asynchronously, and a third thread as a result of a dispatch back to the container to resume processing of the asynchronous resuilt. Other updates include the addition of a MockAsyncContext and support of related request method in the test packages of spring-web and spring-webmvc. Also an upgrade of a Jetty test dependency required to make tests pass. Issue: SPR-9433
2012-07-25 04:00:05 +08:00
exclude group: 'org.eclipse.jetty.orbit', module: 'javax.servlet'
}
compile("org.eclipse.jetty:jetty-server:8.1.5.v20120716") { dep ->
optional dep
exclude group: 'org.eclipse.jetty.orbit', module: 'javax.servlet'
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
Add abstractions for content negotiation Introduced ContentNeogtiationStrategy for resolving the requested media types from an incoming request. The available implementations are based on path extension, request parameter, 'Accept' header, and a fixed default content type. The logic for these implementations is based on equivalent options, previously available only in the ContentNegotiatingViewResolver. Also in this commit is ContentNegotiationManager, the central class to use when configuring content negotiation options. It accepts one or more ContentNeogtiationStrategy instances and delegates to them. The ContentNeogiationManager can now be used to configure the following classes: - RequestMappingHandlerMappingm - RequestMappingHandlerAdapter - ExceptionHandlerExceptionResolver - ContentNegotiatingViewResolver Issue: SPR-8410, SPR-8417, SPR-8418,SPR-8416, SPR-8419,SPR-7722
2012-06-08 20:56:57 +08:00
testCompile project(":spring-context-support") // for JafMediaTypeFactory
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
testCompile "xmlunit:xmlunit:1.2"
}
// pick up ContextLoader.properties in src/main
sourceSets.main.resources.srcDirs += 'src/main/java'
}
project('spring-orm') {
Move integration tests => src/test This commit eliminates the 'integration-tests' subproject in favor of managing these sources under the root project's own 'src' directory. This helps to avoid special-case handling for integration-tests in the Gradle build, e.g. avoiding publication of jars to Artifactory / Maven Central. It is also semantically more correct. This is not a Spring Framework subproject so much as it is a collection of integration tests that span functionality across many subprojects. In this way, it makes sense to place them directly under the root project. Issue: SPR-8116
2012-01-15 05:51:26 +08:00
description = 'Spring Object/Relational Mapping'
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
dependencies {
Remove EBR dependencies where possible Only a select few EBR dependencies now remain, because these dependencies cannot be found elsewhere e.g. atinject-tck, or in the case of Hibernate 3.3.1.GA, to avoid Gradle classpath confusion with Hibernate 4.0.x (because they have different artifactIds). Future efforts will be made to fully eliminate these dependencies in order to ensure we're decoupled completely from EBR. Important note: these remaining EBR dependencies do not constitute a problem when publishing artifacts into Maven Central via oss.sonatype.org, because they are each 'optional' dependencies. It appears that OSO's restriction around transitive dependencies being 'self-contained' within Maven Central only applies to mandatory dependencies (which is a good thing for cases just such as this). Add explicit /ebr-maven-external entry to repositories, as EBR dependencies are not available via /libs-release.
2012-01-19 01:41:44 +08:00
// compiling against both hibernate 3 and 4 here in order to support
// our respective orm.hibernate3 and orm.hibernate4 packages
Require aopalliance dependency for spring-aop A recent commit made aopalliance optional for spring-aop, while continuing to require it for spring-tx. On review, this is probably overly aggressive, and for convenience aopalliance should remain required for spring-aop. There are use cases for which aopalliance is indeed optional, but core functionality such as <aop:scoped-proxy> should never result in a ClassNotFoundException. This commit returns the aopalliance dependency for spring-aop to required status, and also explicitly notes the same dependency in other modules that compile directly against aopalliance types. Issue: SPR-9501
2012-06-13 19:47:47 +08:00
compile("aopalliance:aopalliance:1.0")
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("org.hibernate:com.springsource.org.hibernate:3.3.1.GA", optional)
Upgrade Hibernate from 4.0.0.CR7=>4.1.0.Final spring-orm now successfully builds against hibernate-core and hibernate-entitymanager 4.1.0.Final Issue: SPR-9082
2012-02-09 18:45:05 +08:00
compile("org.hibernate:hibernate-core:4.1.0.Final", optional)
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("org.hibernate:hibernate-cglib-repack:2.1_3", optional)
compile("org.hibernate:hibernate-annotations:3.4.0.GA", optional)
Upgrade Hibernate from 4.0.0.CR7=>4.1.0.Final spring-orm now successfully builds against hibernate-core and hibernate-entitymanager 4.1.0.Final Issue: SPR-9082
2012-02-09 18:45:05 +08:00
compile("org.hibernate:hibernate-entitymanager:4.1.0.Final", optional)
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("org.apache.openjpa:openjpa:1.1.0", optional)
compile("org.eclipse.persistence:org.eclipse.persistence.core:1.0.1", optional)
compile("org.eclipse.persistence:org.eclipse.persistence.jpa:1.0.1", optional)
compile("toplink.essentials:toplink-essentials:2.0-41b", optional)
compile("javax.jdo:jdo-api:3.0", optional)
compile("org.apache.ibatis:ibatis-sqlmap:2.3.4.726", optional)
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
testCompile "javax.servlet:servlet-api:2.5"
testCompile "org.slf4j:slf4j-jcl:1.5.3"
testCompile "commons-dbcp:commons-dbcp:1.2.2"
Remove EBR dependencies where possible Only a select few EBR dependencies now remain, because these dependencies cannot be found elsewhere e.g. atinject-tck, or in the case of Hibernate 3.3.1.GA, to avoid Gradle classpath confusion with Hibernate 4.0.x (because they have different artifactIds). Future efforts will be made to fully eliminate these dependencies in order to ensure we're decoupled completely from EBR. Important note: these remaining EBR dependencies do not constitute a problem when publishing artifacts into Maven Central via oss.sonatype.org, because they are each 'optional' dependencies. It appears that OSO's restriction around transitive dependencies being 'self-contained' within Maven Central only applies to mandatory dependencies (which is a good thing for cases just such as this). Add explicit /ebr-maven-external entry to repositories, as EBR dependencies are not available via /libs-release.
2012-01-19 01:41:44 +08:00
testCompile "org.eclipse.persistence:org.eclipse.persistence.asm:1.0.1"
testCompile "org.eclipse.persistence:org.eclipse.persistence.antlr:1.0.1"
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
compile(project(":spring-web")) {
exclude group: 'javax.persistence', module: 'persistence-api'
}
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile project(":spring-core")
compile project(":spring-beans")
compile(project(":spring-aop"), optional)
compile(project(":spring-context"), optional)
compile project(":spring-tx")
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
compile project(":spring-jdbc")
}
}
project('spring-webmvc') {
description = 'Spring Web MVC'
dependencies {
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile project(":spring-core")
compile project(":spring-expression")
compile project(":spring-beans")
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
compile project(":spring-web")
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile project(":spring-context")
compile(project(":spring-context-support"), optional) // for Velocity support
compile(project(":spring-oxm"), optional) // for MarshallingView
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("org.apache.tiles:tiles-api:2.1.2", optional)
compile("org.apache.tiles:tiles-core:2.1.2", optional)
compile("org.apache.tiles:tiles-jsp:2.1.2", optional)
compile("org.apache.tiles:tiles-servlet:2.1.2", optional)
compile("velocity-tools:velocity-tools-view:1.4", optional)
compile("net.sourceforge.jexcelapi:jxl:2.6.3") { dep ->
optional dep
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
exclude group: 'log4j', module: 'log4j'
}
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("org.apache.poi:poi:3.0.2-FINAL") { dep ->
optional dep
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
exclude group: 'log4j', module: 'log4j'
}
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("javax.servlet:jstl:1.1.2", provided)
compile("org.apache.tomcat:tomcat-servlet-api:7.0.8", provided) // servlet-api 3.0
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
testCompile project(":spring-aop")
Upgrade slf4j-api and -log4j12 dependencies to 1.6.1 Previously depending on 1.5.10 in certain locations, which caused NoClassDefFoundErrors in EhCacheCacheTests and other tests due to mismatches between slf4j -api and -log4j12 versions. With the exception of one transitive dependency via Hibernate 3.3.1.GA, all slf4j dependencies are now pegged at 1.6.1 (and all tests pass).
2012-04-17 16:51:16 +08:00
testCompile("org.slf4j:slf4j-log4j12:1.6.1") {
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
exclude group: 'log4j', module: 'log4j'
}
testCompile "rhino:js:1.7R1"
testCompile "xmlunit:xmlunit:1.2"
testCompile("dom4j:dom4j:1.6.1") {
exclude group: 'xml-apis', module: 'xml-apis'
}
testCompile("jaxen:jaxen:1.1.1") {
exclude group: 'xml-apis', module: 'xml-apis'
exclude group: 'xom', module: 'xom'
exclude group: 'xerces', module: 'xercesImpl'
}
}
// pick up DispatcherServlet.properties in src/main
sourceSets.main.resources.srcDirs += 'src/main/java'
}
project('spring-webmvc-portlet') {
description = 'Spring Web Portlet'
dependencies {
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("javax.servlet:servlet-api:2.5", provided)
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile project(":spring-core")
compile project(":spring-beans")
compile project(":spring-context")
compile project(":spring-web")
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
compile project(":spring-webmvc")
}
// pick up DispatcherPortlet.properties in src/main
sourceSets.main.resources.srcDirs += 'src/main/java'
}
project('spring-test') {
Move integration tests => src/test This commit eliminates the 'integration-tests' subproject in favor of managing these sources under the root project's own 'src' directory. This helps to avoid special-case handling for integration-tests in the Gradle build, e.g. avoiding publication of jars to Artifactory / Maven Central. It is also semantically more correct. This is not a Spring Framework subproject so much as it is a collection of integration tests that span functionality across many subprojects. In this way, it makes sense to place them directly under the root project. Issue: SPR-8116
2012-01-15 05:51:26 +08:00
description = 'Spring TestContext Framework'
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
dependencies {
Improve dependency management for spring-test In Spring 3.1 the spring-test Maven artifact did not have a required dependency on spring-core, but there is practically no part of spring-test that can be used without spring-core. Most test utilities that are intended to be stand-alone utilities in fact use utility classes from spring-core (e.g., ReflectionTestUtils). Even some of the web mocks/stubs use spring-core (e.g., DelegatingServletInputStream). In addition, the current Gradle build configuration for the spring-test module is very simplistic -- in that it does not explicitly list any optional dependencies such as the Servlet and Portlet APIs -- and it defines a 'compile' dependency on spring-webmvc-portlet. The resulting Maven dependencies in the generated POM are therefore not what a typical consumer of the spring-test artifact would reasonably expect. To address these issues, the Gradle build configuration for the spring-test module now explicitly defines the following 'compile' dependencies: - spring-core - spring-webmvc, optional - spring-webmvc-portlet, optional - junit, optional - testng, optional - servlet-api, optional - jsp-api, optional - portlet-api, optional - activation, provided The only required dependency is now spring-core; all other dependencies are 'optional'. Issue: SPR-8861
2012-05-28 08:33:56 +08:00
compile project(":spring-core")
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile(project(":spring-beans"), optional)
compile(project(":spring-context"), optional)
compile(project(":spring-jdbc"), optional)
compile(project(":spring-tx"), optional)
compile(project(":spring-orm"), optional)
compile(project(":spring-web"), optional)
Improve dependency management for spring-test In Spring 3.1 the spring-test Maven artifact did not have a required dependency on spring-core, but there is practically no part of spring-test that can be used without spring-core. Most test utilities that are intended to be stand-alone utilities in fact use utility classes from spring-core (e.g., ReflectionTestUtils). Even some of the web mocks/stubs use spring-core (e.g., DelegatingServletInputStream). In addition, the current Gradle build configuration for the spring-test module is very simplistic -- in that it does not explicitly list any optional dependencies such as the Servlet and Portlet APIs -- and it defines a 'compile' dependency on spring-webmvc-portlet. The resulting Maven dependencies in the generated POM are therefore not what a typical consumer of the spring-test artifact would reasonably expect. To address these issues, the Gradle build configuration for the spring-test module now explicitly defines the following 'compile' dependencies: - spring-core - spring-webmvc, optional - spring-webmvc-portlet, optional - junit, optional - testng, optional - servlet-api, optional - jsp-api, optional - portlet-api, optional - activation, provided The only required dependency is now spring-core; all other dependencies are 'optional'. Issue: SPR-8861
2012-05-28 08:33:56 +08:00
compile(project(":spring-webmvc"), optional)
compile(project(":spring-webmvc-portlet"), optional)
spring-test module now depends on junit:junit-dep The junit:junit Maven artifact includes a bundled version of hamcrest core. For projects that depend on later versions of hamcrest this causes significant issues in terms of dependency management. The spring-test module now depends on junit:junit-dep, thus allowing developers to better manage their test dependencies on a more fine grained level. Also tidied up dependency issues regarding hamcrest-core and hamcrest-all across the build. Issue: SPR-6966
2012-06-10 08:33:46 +08:00
compile("junit:junit-dep:${junitVersion}") { dep ->
optional dep
// We already have hamcrest-all as a global testCompile dependency.
exclude group: 'org.hamcrest', module: 'hamcrest-core'
}
compile("org.testng:testng:6.5.2") { dep ->
optional dep
exclude group: 'junit', module: 'junit'
// We already have hamcrest-all as a global testCompile dependency.
exclude group: 'org.hamcrest', module: 'hamcrest-core'
}
Improve dependency management for spring-test In Spring 3.1 the spring-test Maven artifact did not have a required dependency on spring-core, but there is practically no part of spring-test that can be used without spring-core. Most test utilities that are intended to be stand-alone utilities in fact use utility classes from spring-core (e.g., ReflectionTestUtils). Even some of the web mocks/stubs use spring-core (e.g., DelegatingServletInputStream). In addition, the current Gradle build configuration for the spring-test module is very simplistic -- in that it does not explicitly list any optional dependencies such as the Servlet and Portlet APIs -- and it defines a 'compile' dependency on spring-webmvc-portlet. The resulting Maven dependencies in the generated POM are therefore not what a typical consumer of the spring-test artifact would reasonably expect. To address these issues, the Gradle build configuration for the spring-test module now explicitly defines the following 'compile' dependencies: - spring-core - spring-webmvc, optional - spring-webmvc-portlet, optional - junit, optional - testng, optional - servlet-api, optional - jsp-api, optional - portlet-api, optional - activation, provided The only required dependency is now spring-core; all other dependencies are 'optional'. Issue: SPR-8861
2012-05-28 08:33:56 +08:00
compile("javax.servlet:servlet-api:2.5", optional)
compile("javax.servlet.jsp:jsp-api:2.1", optional)
compile("javax.portlet:portlet-api:2.0", optional)
compile("javax.activation:activation:1.0", provided)
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
testCompile "org.slf4j:slf4j-jcl:1.5.3"
}
}
project('spring-struts') {
description = 'Spring Struts'
dependencies {
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
compile project(":spring-core")
compile project(":spring-beans")
compile project(":spring-context")
compile project(":spring-web")
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
compile project(":spring-webmvc")
compile "struts:struts:1.2.9"
compile "commons-beanutils:commons-beanutils:1.7.0"
Generate Maven Central-compatible poms Understanding Gradle pom generation ------------------------------------------- All spring-* subprojects have had Gradle's 'maven' plugin applied to them. This means that one can run `gradle install`, and POMs will be generated according to the metadata in the build.gradle file. The 'customizePom' routine added by this commit hooks into this generation process in order to add elements to the pom required for entry into Maven Central via oss.sonatype.org[1]. This pom generation happens on-the-fly during `gradle install` and the generated poms exist only in your local .m2 cache. Therefore, you will not see the poms on the source tree after this command. Handling optional and provided dependencies ------------------------------------------- Note particularly the handling of 'optional' and 'provided' dependencies. Gradle does not have a first class notion for these concepts, nor are they significant to the actual Gradle build process, but they are important when publishing POMs for consumption via Maven Central and other Maven-compatible repositories. <optional>true</optional> indicates that a dependency need not be downloaded when resolving artifacts. e.g. spring-context has an compile-time dependency on cglib, but when a Spring user resolves spring-context from Maven Central, cglib should *not* automatically be downloaded at the same time. This is because the core functionality within spring-context can operate just fine without cglib on the classpath; it is only if the user chooses explicitly to use certain functionality, e.g. @Configuration classes, which do require cglib, that the user must declare an explicit dependency in their own build script on cglib. Marking these kinds of dependencies as 'optional' provides a kind of built in 'documentation' about which version of cglib the user should declare if in fact he wishes to. Spring has a great many compile-time dependencies, but in fact very few mandatory runtime dependencies. Therefore, *most* of Spring's dependencies are optional. <scope>provided</scope> is similar to 'optional', in that dependencies so marked should not be automatically downloaded during dependency resolution, but indicates rather that they are expected to have been provided by the user application runtime environment. For example, the Servlet API is in fact a required runtime dependency for spring-webmvc, but it is expected that it will be available via the user's servlet container classpath. Again, it serves here as a kind of 'documentation' that spring-webmvc does in fact expect the servlet api to be available, and furthermore which (minimum) version. This commit adds two closures named 'optional' and 'provided' as well as two arrays (optionalDeps, providedDeps) for tracking which dependencies are optional or provided. An optional dependency is declared as follows: compile("group:artifact:version", optional) Here, the optional closure accepts the dependency argument implicitly, and appends it to the 'optionalDeps' array. Then, during pom generation (again, the customizePom routine), these arrays are interrogated, and pom <dependency> elements are updated with <optional>true</optional> or <scope>provided</scope> as appropriate. Thanks to the Spock framework for inspiration on this approach[2]. [1] http://bit.ly/wauOqP (Sonatype's central sync requirements) [2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
2012-01-19 19:29:16 +08:00
compile("javax.servlet:servlet-api:2.5", provided)
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
testCompile project(":spring-test")
}
}
project('spring-aspects') {
description = 'Spring Aspects'
Fix and refactor spring-aspects build - Fix compileTestJava issue in which test classes were not being compiled or run - Use built-in eclipse.project DSL instead of withXml closure to add AspectJ nature and builder - Rename {aspectJ=>aspects}.gradle and format source
2012-01-21 20:27:14 +08:00
apply from: 'aspects.gradle'
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
dependencies {
Update dependencies for spring-aspects - Explicitly specify compile-time dependencies on other spring-* modules, primarily for accuracy in pom generation and ensuring minimal dependencies for users of spring-aspects. - Remove use of p: namespace from annotation-cache-aspectj.xml to avoid parser-related test failures under Eclipse (likely due to classpath differences between Gradle and Eclipse).
2012-06-01 21:35:29 +08:00
compile(project(":spring-beans"), optional) // for @Configurable support
compile(project(":spring-aop"), optional) // for @Async support
compile(project(":spring-context"), optional) // for @Enable* support
compile(project(":spring-context-support"), optional) // for JavaMail support
compile(project(":spring-tx"), optional) // for JPA, @Transactional support
compile(project(":spring-orm"), optional) // for JPA exception translation support
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
aspects project(":spring-orm")
Upgrade AspectJ from 1.6.8 to 1.6.12 - Spring remains compatible against AJ version 1.6.8, but is now compiling and testing against 1.6.12 - Encountered what appears to be an AJ bug introduced in 1.6.10: an assertion in org.aspectj.weaver.UnresolvedType causes a false negative failure when encountering org.springframework.io.Resource arrays, e.g. "[org.springframework.io.Resource@xxx". This problem has been reported to the AJ team and in the meantime, the recommended workaround is to disable assertions either completely, or at least selectively with -disableassertions:org.aspectj.weaver.UnresolvedType Issue: SPR-7989, SPR-9272
2012-04-15 00:05:20 +08:00
ajc "org.aspectj:aspectjtools:${aspectjVersion}"
compile "org.aspectj:aspectjrt:${aspectjVersion}"
Update dependencies for spring-aspects - Explicitly specify compile-time dependencies on other spring-* modules, primarily for accuracy in pom generation and ensuring minimal dependencies for users of spring-aspects. - Remove use of p: namespace from annotation-cache-aspectj.xml to avoid parser-related test failures under Eclipse (likely due to classpath differences between Gradle and Eclipse).
2012-06-01 21:35:29 +08:00
testCompile project(":spring-core") // for CodeStyleAspect
compile project(":spring-beans") // for 'p' namespace visibility
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
testCompile project(":spring-test")
}
Fix and refactor spring-aspects build - Fix compileTestJava issue in which test classes were not being compiled or run - Use built-in eclipse.project DSL instead of withXml closure to add AspectJ nature and builder - Rename {aspectJ=>aspects}.gradle and format source
2012-01-21 20:27:14 +08:00
eclipse.project {
natures += 'org.eclipse.ajdt.ui.ajnature'
Remove javabuilder from spring-aspects .project Previously, the build script was configured to add ajbuilder to the set of Eclipse/STS build commands, meaning that both javabuilder and ajbuilder would be present for spring-aspects. This causes unpredictable behavior, as these two builders compete with each other. As ajbuilder is a functional superset of javabuilder, this commit ensures that only the former is present for spring-aspects' .project file. Also removed warning language in import-into-eclipse.sh about spring-aspects failing after adding Git support, as this intermittent problem was almost certainly an artifact of the situation described above.
2012-02-02 08:06:16 +08:00
buildCommands = [new org.gradle.plugins.ide.eclipse.model.
BuildCommand('org.eclipse.ajdt.core.ajbuilder')]
Fix and refactor spring-aspects build - Fix compileTestJava issue in which test classes were not being compiled or run - Use built-in eclipse.project DSL instead of withXml closure to add AspectJ nature and builder - Rename {aspectJ=>aspects}.gradle and format source
2012-01-21 20:27:14 +08:00
}
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
Generate -docs, -schema and -dist zips - Add 'api' gradle task to generate project-wide API Javadoc results in <root>/build/api - Add docsZip task including api and reference documentation suitable for publication to http://static.springframework.org/docs/spring-framework - Add schemaZip task including all spring-* XSD files suitable for publication to http://static.springframework.org/schema - Add distZip task to include all libs, docs and schema - filter src/dist/*.txt for ${copyright} and ${version} - copy legal (notice, license) dynamically into individual jar files - copy legal and readme files into root of distribution zip - Refactor location of 'wrapper' task Each of the zip tasks (docsZip, schemaZip, distZip) have been added to the 'archives' configuration, meaning that (a) they will be built automatically with `gradle build` and (b) will be published automatically to artifactory when using the Artifactory Gradle plugin and/or Artifactory Bamboo integration.
2012-01-17 05:28:06 +08:00
configure(rootProject) {
description = 'Spring Framework'
apply plugin: 'docbook-reference'
reference {
sourceDir = file('src/reference/docbook')
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
Generate -docs, -schema and -dist zips - Add 'api' gradle task to generate project-wide API Javadoc results in <root>/build/api - Add docsZip task including api and reference documentation suitable for publication to http://static.springframework.org/docs/spring-framework - Add schemaZip task including all spring-* XSD files suitable for publication to http://static.springframework.org/schema - Add distZip task to include all libs, docs and schema - filter src/dist/*.txt for ${copyright} and ${version} - copy legal (notice, license) dynamically into individual jar files - copy legal and readme files into root of distribution zip - Refactor location of 'wrapper' task Each of the zip tasks (docsZip, schemaZip, distZip) have been added to the 'archives' configuration, meaning that (a) they will be built automatically with `gradle build` and (b) will be published automatically to artifactory when using the Artifactory Gradle plugin and/or Artifactory Bamboo integration.
2012-01-17 05:28:06 +08:00
// don't publish the default jar for the root project
configurations.archives.artifacts.clear()
dependencies { // for integration tests
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
testCompile project(":spring-core")
testCompile project(":spring-beans")
testCompile project(":spring-aop")
testCompile project(":spring-expression")
testCompile project(":spring-context")
testCompile project(":spring-tx")
testCompile project(":spring-jdbc")
Generate -docs, -schema and -dist zips - Add 'api' gradle task to generate project-wide API Javadoc results in <root>/build/api - Add docsZip task including api and reference documentation suitable for publication to http://static.springframework.org/docs/spring-framework - Add schemaZip task including all spring-* XSD files suitable for publication to http://static.springframework.org/schema - Add distZip task to include all libs, docs and schema - filter src/dist/*.txt for ${copyright} and ${version} - copy legal (notice, license) dynamically into individual jar files - copy legal and readme files into root of distribution zip - Refactor location of 'wrapper' task Each of the zip tasks (docsZip, schemaZip, distZip) have been added to the 'archives' configuration, meaning that (a) they will be built automatically with `gradle build` and (b) will be published automatically to artifactory when using the Artifactory Gradle plugin and/or Artifactory Bamboo integration.
2012-01-17 05:28:06 +08:00
testCompile project(":spring-test")
Test pom generation and update optional deps Gradle-generated poms thoroughly tested against 3.1.1 versions, with an eye toward making as many spring-* dependencies optional as possible. All spring-* modules now declare a Gradle dependency on any other spring-* module where there is a direct compile-time usage of the sources in that module. Previously, dependency declarations were minimal, letting transitive resolution do most of the work. However, this creates less than ideal poms and is generally not very informative. So for example, spring-jdbc uses spring-core, spring-beans and spring-tx classes directly. Therefore it has the following declarations: compile project(":spring-core") compile project(":spring-beans") compile project(":spring-tx") spring-core depends on spring-asm, but spring-jdbc does not use spring-asm classes directly. Therefore spring-jdbc does not declare a dependency on spring-asm. Transitive resolution is fine in such a case. As for optional dependencies, it is a matter of degrees what constitutes optional. A rule of thumb is whether there are legitimate and likely use cases in which the module can be used without needing the dependency. spring-jdbc has only one compile-time dependency on spring-context classes, and that's in JndiDataSourceLookup. It is certainly reasonable to imagine using spring-jdbc without JNDI, therefore the spring-context dependency is declared optional as follows: compile(project(":spring-context"), optional) // for JndiDataSourceLookup
2012-05-28 20:19:09 +08:00
testCompile project(":spring-web")
Generate -docs, -schema and -dist zips - Add 'api' gradle task to generate project-wide API Javadoc results in <root>/build/api - Add docsZip task including api and reference documentation suitable for publication to http://static.springframework.org/docs/spring-framework - Add schemaZip task including all spring-* XSD files suitable for publication to http://static.springframework.org/schema - Add distZip task to include all libs, docs and schema - filter src/dist/*.txt for ${copyright} and ${version} - copy legal (notice, license) dynamically into individual jar files - copy legal and readme files into root of distribution zip - Refactor location of 'wrapper' task Each of the zip tasks (docsZip, schemaZip, distZip) have been added to the 'archives' configuration, meaning that (a) they will be built automatically with `gradle build` and (b) will be published automatically to artifactory when using the Artifactory Gradle plugin and/or Artifactory Bamboo integration.
2012-01-17 05:28:06 +08:00
testCompile project(":spring-webmvc-portlet")
Upgrade Hibernate from 4.0.0.CR7=>4.1.0.Final spring-orm now successfully builds against hibernate-core and hibernate-entitymanager 4.1.0.Final Issue: SPR-9082
2012-02-09 18:45:05 +08:00
testCompile "org.hibernate:hibernate-core:4.1.0.Final"
Generate -docs, -schema and -dist zips - Add 'api' gradle task to generate project-wide API Javadoc results in <root>/build/api - Add docsZip task including api and reference documentation suitable for publication to http://static.springframework.org/docs/spring-framework - Add schemaZip task including all spring-* XSD files suitable for publication to http://static.springframework.org/schema - Add distZip task to include all libs, docs and schema - filter src/dist/*.txt for ${copyright} and ${version} - copy legal (notice, license) dynamically into individual jar files - copy legal and readme files into root of distribution zip - Refactor location of 'wrapper' task Each of the zip tasks (docsZip, schemaZip, distZip) have been added to the 'archives' configuration, meaning that (a) they will be built automatically with `gradle build` and (b) will be published automatically to artifactory when using the Artifactory Gradle plugin and/or Artifactory Bamboo integration.
2012-01-17 05:28:06 +08:00
testCompile "javax.servlet:servlet-api:2.5"
}
task api(type: Javadoc) {
group = 'Documentation'
description = 'Generates aggregated Javadoc API documentation.'
title = "${rootProject.description} ${version} API"
options.memberLevel = org.gradle.external.javadoc.JavadocMemberLevel.PROTECTED
options.author = true
options.header = rootProject.description
options.overview = 'src/api/overview.html'
Add splitIndex Javadoc option to the root project Splits the very large index page with all classes into individual pages organized by first letter. Issue: SPR-4984
2012-06-15 00:17:54 +08:00
options.splitIndex = true
Generate -docs, -schema and -dist zips - Add 'api' gradle task to generate project-wide API Javadoc results in <root>/build/api - Add docsZip task including api and reference documentation suitable for publication to http://static.springframework.org/docs/spring-framework - Add schemaZip task including all spring-* XSD files suitable for publication to http://static.springframework.org/schema - Add distZip task to include all libs, docs and schema - filter src/dist/*.txt for ${copyright} and ${version} - copy legal (notice, license) dynamically into individual jar files - copy legal and readme files into root of distribution zip - Refactor location of 'wrapper' task Each of the zip tasks (docsZip, schemaZip, distZip) have been added to the 'archives' configuration, meaning that (a) they will be built automatically with `gradle build` and (b) will be published automatically to artifactory when using the Artifactory Gradle plugin and/or Artifactory Bamboo integration.
2012-01-17 05:28:06 +08:00
options.links(
'http://docs.jboss.org/jbossas/javadoc/4.0.5/connector'
)
source subprojects.collect { project ->
project.sourceSets.main.allJava
}
destinationDir = new File(buildDir, "api")
classpath = files(subprojects.collect { project ->
project.sourceSets.main.compileClasspath
})
maxMemory = '1024m'
}
task docsZip(type: Zip) {
group = 'Distribution'
classifier = 'docs'
description = "Builds -${classifier} archive containing api and reference " +
"for deployment at static.springframework.org/spring-framework/docs."
from('src/dist') {
include 'changelog.txt'
}
from (api) {
into 'api'
}
from (reference) {
into 'reference'
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
Generate -docs, -schema and -dist zips - Add 'api' gradle task to generate project-wide API Javadoc results in <root>/build/api - Add docsZip task including api and reference documentation suitable for publication to http://static.springframework.org/docs/spring-framework - Add schemaZip task including all spring-* XSD files suitable for publication to http://static.springframework.org/schema - Add distZip task to include all libs, docs and schema - filter src/dist/*.txt for ${copyright} and ${version} - copy legal (notice, license) dynamically into individual jar files - copy legal and readme files into root of distribution zip - Refactor location of 'wrapper' task Each of the zip tasks (docsZip, schemaZip, distZip) have been added to the 'archives' configuration, meaning that (a) they will be built automatically with `gradle build` and (b) will be published automatically to artifactory when using the Artifactory Gradle plugin and/or Artifactory Bamboo integration.
2012-01-17 05:28:06 +08:00
}
task schemaZip(type: Zip) {
group = 'Distribution'
classifier = 'schema'
description = "Builds -${classifier} archive containing all " +
"XSDs for deployment at static.springframework.org/schema."
subprojects.each { subproject ->
def Properties schemas = new Properties();
subproject.sourceSets.main.resources.find {
it.path.endsWith('META-INF/spring.schemas')
}?.withInputStream { schemas.load(it) }
for (def key : schemas.keySet()) {
def shortName = key.replaceAll(/http.*schema.(.*).spring-.*/, '$1')
assert shortName != key
File xsdFile = subproject.sourceSets.main.resources.find {
it.path.endsWith(schemas.get(key))
}
assert xsdFile != null
into (shortName) {
from xsdFile.path
}
}
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}
}
Generate -docs, -schema and -dist zips - Add 'api' gradle task to generate project-wide API Javadoc results in <root>/build/api - Add docsZip task including api and reference documentation suitable for publication to http://static.springframework.org/docs/spring-framework - Add schemaZip task including all spring-* XSD files suitable for publication to http://static.springframework.org/schema - Add distZip task to include all libs, docs and schema - filter src/dist/*.txt for ${copyright} and ${version} - copy legal (notice, license) dynamically into individual jar files - copy legal and readme files into root of distribution zip - Refactor location of 'wrapper' task Each of the zip tasks (docsZip, schemaZip, distZip) have been added to the 'archives' configuration, meaning that (a) they will be built automatically with `gradle build` and (b) will be published automatically to artifactory when using the Artifactory Gradle plugin and/or Artifactory Bamboo integration.
2012-01-17 05:28:06 +08:00
task distZip(type: Zip, dependsOn: [docsZip, schemaZip]) {
group = 'Distribution'
classifier = 'dist'
description = "Builds -${classifier} archive, containing all jars and docs, " +
"suitable for community download page."
Add Gradle task for building zip with dependencies Some Spring Framework users and teams cannot use transitive dependency management tools like Maven, Gradle and Ivy. For them, a `distZip` task has been added to allow for creating a Spring Framework distribution from source that includes all optional and required runtime dependencies for all modules of the framework. This 'dist-with-deps' zip is not published to the SpringSource repository nor to the SpringSource community download page. It is strictly an optional task introduced as a convenience to the users mentioned above. Detailed instructions for building this zip locally have been added to the wiki and the README has been updated with a link to that new doc. Issue: SPR-6575
2012-06-19 22:00:22 +08:00
ext.baseDir = "${project.name}-${project.version}";
Generate -docs, -schema and -dist zips - Add 'api' gradle task to generate project-wide API Javadoc results in <root>/build/api - Add docsZip task including api and reference documentation suitable for publication to http://static.springframework.org/docs/spring-framework - Add schemaZip task including all spring-* XSD files suitable for publication to http://static.springframework.org/schema - Add distZip task to include all libs, docs and schema - filter src/dist/*.txt for ${copyright} and ${version} - copy legal (notice, license) dynamically into individual jar files - copy legal and readme files into root of distribution zip - Refactor location of 'wrapper' task Each of the zip tasks (docsZip, schemaZip, distZip) have been added to the 'archives' configuration, meaning that (a) they will be built automatically with `gradle build` and (b) will be published automatically to artifactory when using the Artifactory Gradle plugin and/or Artifactory Bamboo integration.
2012-01-17 05:28:06 +08:00
from('src/dist') {
include 'readme.txt'
include 'license.txt'
include 'notice.txt'
into "${baseDir}"
expand(copyright: new Date().format('yyyy'), version: project.version)
}
from(zipTree(docsZip.archivePath)) {
into "${baseDir}/docs"
}
from(zipTree(schemaZip.archivePath)) {
into "${baseDir}/schema"
}
subprojects.each { subproject ->
into ("${baseDir}/libs") {
from subproject.jar
if (subproject.tasks.findByPath('sourcesJar')) {
from subproject.sourcesJar
}
if (subproject.tasks.findByPath('javadocJar')) {
from subproject.javadocJar
}
}
}
}
Add Gradle task for building zip with dependencies Some Spring Framework users and teams cannot use transitive dependency management tools like Maven, Gradle and Ivy. For them, a `distZip` task has been added to allow for creating a Spring Framework distribution from source that includes all optional and required runtime dependencies for all modules of the framework. This 'dist-with-deps' zip is not published to the SpringSource repository nor to the SpringSource community download page. It is strictly an optional task introduced as a convenience to the users mentioned above. Detailed instructions for building this zip locally have been added to the wiki and the README has been updated with a link to that new doc. Issue: SPR-6575
2012-06-19 22:00:22 +08:00
// Create an distribution that contains all dependencies (required and optional).
// Not published by default; only for use when building from source.
task depsZip(type: Zip, dependsOn: distZip) { zipTask ->
group = 'Distribution'
classifier = 'dist-with-deps'
description = "Builds -${classifier} archive, containing everything " +
"in the -${distZip.classifier} archive plus all runtime dependencies."
from zipTree(distZip.archivePath)
gradle.taskGraph.whenReady { taskGraph ->
if (taskGraph.hasTask(":${zipTask.name}")) {
def projectNames = rootProject.subprojects*.name
def artifacts = new HashSet()
subprojects.each { subproject ->
subproject.configurations.runtime.resolvedConfiguration.resolvedArtifacts.each { artifact ->
def dependency = artifact.moduleVersion.id
if (!projectNames.contains(dependency.name)) {
artifacts << artifact.file
}
}
}
zipTask.from(artifacts) {
into "${distZip.baseDir}/deps"
}
}
}
}
Generate -docs, -schema and -dist zips - Add 'api' gradle task to generate project-wide API Javadoc results in <root>/build/api - Add docsZip task including api and reference documentation suitable for publication to http://static.springframework.org/docs/spring-framework - Add schemaZip task including all spring-* XSD files suitable for publication to http://static.springframework.org/schema - Add distZip task to include all libs, docs and schema - filter src/dist/*.txt for ${copyright} and ${version} - copy legal (notice, license) dynamically into individual jar files - copy legal and readme files into root of distribution zip - Refactor location of 'wrapper' task Each of the zip tasks (docsZip, schemaZip, distZip) have been added to the 'archives' configuration, meaning that (a) they will be built automatically with `gradle build` and (b) will be published automatically to artifactory when using the Artifactory Gradle plugin and/or Artifactory Bamboo integration.
2012-01-17 05:28:06 +08:00
artifacts {
archives docsZip
archives schemaZip
archives distZip
}
task wrapper(type: Wrapper) {
description = 'Generates gradlew[.bat] scripts'
Upgrade to Gradle 1.1 GA Issue: SPR-9660
2012-08-08 14:44:51 +08:00
gradleVersion = '1.1'
Generate -docs, -schema and -dist zips - Add 'api' gradle task to generate project-wide API Javadoc results in <root>/build/api - Add docsZip task including api and reference documentation suitable for publication to http://static.springframework.org/docs/spring-framework - Add schemaZip task including all spring-* XSD files suitable for publication to http://static.springframework.org/schema - Add distZip task to include all libs, docs and schema - filter src/dist/*.txt for ${copyright} and ${version} - copy legal (notice, license) dynamically into individual jar files - copy legal and readme files into root of distribution zip - Refactor location of 'wrapper' task Each of the zip tasks (docsZip, schemaZip, distZip) have been added to the 'archives' configuration, meaning that (a) they will be built automatically with `gradle build` and (b) will be published automatically to artifactory when using the Artifactory Gradle plugin and/or Artifactory Bamboo integration.
2012-01-17 05:28:06 +08:00
}
Introduce Gradle-based build - Use recent Gradle 1.0-milestone-8 snapshot - Add initial cut of build.gradle able to compile/test all modules - Update .gitignore - Generate Gradle wrapper scripts - Remove all Eclipse metadata files - Temporarily @Ignore tests that do not pass under Gradle
2011-12-15 08:56:31 +08:00
}