tchekai704
/
src-spring-framework
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Spring Framework
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
5225 Commits
19 Branches
274 Tags
318 MiB
Tree: e8392f83c9
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'e8392f83c9'
${ noResults }
src-spring-framework/build.gradle

597 lines
20 KiB
Raw Normal View History Unescape

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
13 years ago
buildscript {
repositories {
Upgrade to docbook-reference-plugin 0.1.3
13 years ago
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
13 years ago
}
dependencies {
Upgrade to docbook-reference-plugin 0.1.5 - Fixes deprecation warnings associated with recent upgrade to Gradle 1.0-rc1
13 years ago
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
13 years ago
}
}
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
13 years ago
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
13 years ago
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
13 years ago
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
13 years ago
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
13 years ago
ext.aspectjVersion = '1.6.12'
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
13 years ago
[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.
13 years ago
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
13 years ago
}
dependencies {
Upgrade to JUnit 4.10 Spring currently builds against JUnit 4.9; however, in order to ensure that the Spring TestContext Framework builds and runs against JUnit 4.10 without issues and in order to investigate the possibility of integrating with newer JUnit features, we are upgrading to JUnit 4.10. Issue: SPR-9277
13 years ago
testCompile "junit:junit: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
13 years ago
testCompile "org.easymock:easymock:2.5.1"
testCompile "org.hamcrest:hamcrest-all:1.1"
}
// 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
13 years ago
}
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
13 years ago
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.
13 years ago
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.
13 years ago
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.
13 years ago
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
13 years ago
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.
13 years ago
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
13 years ago
task sourcesJar(type: Jar, dependsOn:classes) {
classifier = 'sources'
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.
13 years ago
from sourceSets.main.allJava
}
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
13 years ago
}
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.
13 years ago
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
13 years ago
}
}
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.
13 years ago
project("spring-asm") {
description = 'Spring ASM'
Upgrade to Gradle 1.0-rc1 - Fix deprecation warnings about dynamic properties; favor use of "extra properties extensions" per [1] - Certain such deprecations are still issued due to violations within the docbook-reference plugin. These will be fixed in an upcoming revision of the plugin, at which point spring-framework will upgrade to depend on it and these warnings will be eliminated [1] http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html Issue: SPR-9327
13 years ago
ext.asmVersion = '2.2.3'
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.
13 years ago
configurations {
asm
jarjar
}
dependencies {
asm "asm:asm:${asmVersion}@jar", "asm:asm-commons:${asmVersion}@jar"
jarjar 'com.googlecode.jarjar:jarjar:1.1'
}
task repackageAsm(type: Jar) { jar ->
jar.baseName = "asm-repack"
jar.version = asmVersion
doLast() {
project.ant {
taskdef name: "jarjar", classname: "com.tonicsystems.jarjar.JarJarTask",
classpath: configurations.jarjar.asPath
jarjar(destfile: archivePath, index: "true", filesetmanifest: "merge") {
configurations.asm.each { jarfile ->
zipfileset(src: jarfile)
}
rule(pattern: 'org.objectweb.asm.**', result: 'org.springframework.asm.@1')
}
}
}
}
jar {
dependsOn repackageAsm
from(zipTree(repackageAsm.archivePath)) {
exclude 'META-INF/INDEX.LIST'
}
}
}
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
13 years ago
project('spring-core') {
description = 'Spring Core'
dependencies {
// depend on spring-asm project in order to have it show up as a
// <dependency> in the generated pom
compile project(":spring-asm")
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
13 years ago
// depend directly on the spring-asm jar to avoid errors in Eclipse/STS
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
13 years ago
compile files(project(":spring-asm").jar.archivePath) {
builtBy project(":spring-asm").jar
}
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
13 years ago
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
13 years ago
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
13 years ago
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
13 years ago
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
13 years ago
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"
}
}
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
13 years ago
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
13 years ago
}
}
project('spring-aop') {
description = 'Spring AOP'
dependencies {
compile project(":spring-beans")
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
13 years ago
compile("com.jamonapi:jamon:2.4", optional)
compile("aopalliance:aopalliance:1.0", 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
13 years ago
}
}
project('spring-expression') {
description = 'Spring Expression Language (SpEL)'
dependencies {
compile project(":spring-core")
}
}
project('spring-instrument') {
description = 'Spring Instrument'
dependencies {
compile project(":spring-core")
}
}
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
13 years ago
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
13 years ago
}
}
project('spring-context') {
description = 'Spring Context'
dependencies {
compile project(":spring-aop")
compile project(":spring-expression")
compile project(":spring-instrument")
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
13 years ago
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
13 years ago
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
13 years ago
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.
13 years ago
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
13 years ago
compile("joda-time:joda-time:1.6", optional)
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).
13 years ago
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
13 years ago
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
13 years ago
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.
13 years ago
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
13 years ago
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
13 years ago
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
13 years ago
}
project('spring-tx') {
description = 'Spring Transaction'
dependencies {
compile project(":spring-context")
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
13 years ago
compile("com.ibm.websphere:uow:6.0.2.17", provided)
compile("javax.resource:connector-api:1.5", 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
13 years ago
compile "aopalliance:aopalliance:1.0" // NOT optional, as opposed to in :spring-aop
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).
13 years ago
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
13 years ago
dependencies {
compile project(":spring-context")
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
13 years ago
compile("com.thoughtworks.xstream:xstream:1.3.1", optional)
compile("com.sun.xml.bind:jaxb-impl:2.1.7", optional)
compile("org.jibx:jibx-run:1.1.5", optional)
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
13 years ago
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).
13 years ago
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
13 years ago
}
}
project('spring-jms') {
description = 'Spring JMS'
dependencies {
compile project(":spring-oxm")
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
13 years ago
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
13 years ago
}
}
project('spring-jdbc') {
description = 'Spring JDBC'
dependencies {
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
13 years ago
compile("c3p0:c3p0:0.9.1.2", optional)
compile("hsqldb:hsqldb:1.8.0.7", optional)
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)
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
13 years ago
}
}
project('spring-context-support') {
description = 'Spring Context Support'
dependencies {
compile project(":spring-jdbc")
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
13 years ago
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
13 years ago
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
13 years ago
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)
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
13 years ago
testCompile "hsqldb:hsqldb:1.8.0.10"
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 {
compile project(":spring-oxm")
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
13 years ago
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)
compile("org.apache.httpcomponents:httpclient:4.1.1", optional)
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
13 years ago
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
13 years ago
compile("taglibs:standard:1.1.2", optional)
compile("org.mortbay.jetty:jetty:6.1.9") { 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
13 years ago
exclude group: 'org.mortbay.jetty', module: 'servlet-api-2.5'
}
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
13 years ago
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
13 years ago
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.
13 years ago
// compiling against both hibernate 3 and 4 here in order to support
// our respective orm.hibernate3 and orm.hibernate4 packages
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
13 years ago
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
13 years ago
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
13 years ago
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
13 years ago
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
13 years ago
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
13 years ago
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.
13 years ago
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
13 years ago
compile(project(":spring-web")) {
exclude group: 'javax.persistence', module: 'persistence-api'
}
compile project(":spring-jdbc")
}
}
project('spring-webmvc') {
description = 'Spring Web MVC'
dependencies {
compile project(":spring-web")
compile project(":spring-orm")
compile project(":spring-context-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
13 years ago
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
13 years ago
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
13 years ago
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
13 years ago
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
13 years ago
compile("javax.servlet:jstl:1.1.2", provided)
compile("org.apache.tomcat:tomcat-servlet-api:7.0.8", provided) // servlet-api 3.0
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).
13 years ago
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
13 years ago
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
13 years ago
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
13 years ago
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
13 years ago
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
13 years ago
dependencies {
compile project(":spring-webmvc-portlet")
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
13 years ago
compile("javax.activation:activation:1.0", provided)
compile("org.testng:testng:5.10:jdk15", optional)
Upgrade to JUnit 4.10 Spring currently builds against JUnit 4.9; however, in order to ensure that the Spring TestContext Framework builds and runs against JUnit 4.10 without issues and in order to investigate the possibility of integrating with newer JUnit features, we are upgrading to JUnit 4.10. Issue: SPR-9277
13 years ago
compile("junit:junit:4.10", 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
13 years ago
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
13 years ago
testCompile "org.slf4j:slf4j-jcl:1.5.3"
}
}
project('spring-struts') {
description = 'Spring Struts'
dependencies {
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
13 years ago
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
13 years ago
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
13 years ago
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
13 years ago
dependencies {
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.
13 years ago
compile project(":spring-orm")
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
13 years ago
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
13 years ago
ajc "org.aspectj:aspectjtools:${aspectjVersion}"
compile "org.aspectj:aspectjrt:${aspectjVersion}"
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
13 years ago
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
13 years ago
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.
13 years ago
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
13 years ago
}
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
13 years ago
}
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.
13 years ago
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
13 years ago
}
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.
13 years ago
// don't publish the default jar for the root project
configurations.archives.artifacts.clear()
dependencies { // for integration tests
testCompile project(":spring-test")
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
13 years ago
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.
13 years ago
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'
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
13 years ago
}
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.
13 years ago
}
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
13 years ago
}
}
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.
13 years ago
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."
Upgrade to Gradle 1.0-rc1 - Fix deprecation warnings about dynamic properties; favor use of "extra properties extensions" per [1] - Certain such deprecations are still issued due to violations within the docbook-reference plugin. These will be fixed in an upcoming revision of the plugin, at which point spring-framework will upgrade to depend on it and these warnings will be eliminated [1] http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html Issue: SPR-9327
13 years ago
def 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.
13 years ago
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
}
}
}
}
artifacts {
archives docsZip
archives schemaZip
archives distZip
}
task wrapper(type: Wrapper) {
description = 'Generates gradlew[.bat] scripts'
Upgrade to Gradle 1.0-rc1 - Fix deprecation warnings about dynamic properties; favor use of "extra properties extensions" per [1] - Certain such deprecations are still issued due to violations within the docbook-reference plugin. These will be fixed in an upcoming revision of the plugin, at which point spring-framework will upgrade to depend on it and these warnings will be eliminated [1] http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html Issue: SPR-9327
13 years ago
gradleVersion = '1.0-rc-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.
13 years ago
}
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
13 years ago
}