tchekai704/src-spring-framework - src-spring-framework - Gitea

Author	SHA1	Message	Date
Phillip Webb	0751b2cbeb	Convert Gradle build to use new propdeps-plugin Replace existing 'optional' and 'provided' Spring specific build extensions with a new Gradle propdeps-plugin. Optional and Provided dependencies are now defined use dependency configurations. The new plugin does not currently support the notion of optional runtime dependencies. All optional dependencies are implicitly part of the 'compile' scope. This is an intentional design decision that aims to keep both the plugin and the build simple. Since optional dependencies are non-transitive this restriction should not cause any real problems for existing users. The only existing dependency affected is 'commons-io' in the 'spring-beans' project, however, this was an optional compile scope dependency in the previous Spring 3.1 release. Both provided and optional dependencies are no longer exported from generated eclipse .classpath files. This fixes several tests that would previously fail when running within eclipse. The servlet-api specific elements of ide.gradle are also no longer required. Issue: SPR-9656, SPR-10070	12 years ago
Phillip Webb	90cfdbb040	Polish quote styles in gradle files Replace singe quote-marks with double quote-marks when possible for a more consistent style.	12 years ago
Phillip Webb	a268528726	Polish .gradle file formatting to use tabs Replace spaces with tabs for consistency with Java source code	12 years ago
Chris Beams	d4fb1c8d63	Refactor Gradle script naming and organization - inline test-mvc and tiles3 .gradle files for clarity - rename merge-dist.gradle to merge-artifacts.gradle - polish Javadoc for merge-artifacts.gradle - move merge-artifacts.gradle into gradle subdirectory - move publish-maven.gradle into gradle subdirectory	12 years ago
Rob Winch	39d419bbc3	Support Gradle/maven with multi version artifacts Previously the publish-maven.gradle only supported having a single artifact be marked as optional or provided. This causes problems now that we are building modules that support multiple versions of an artifact. For example, we compile against two versions of Tiles artifacts with identical names, both of which need to be marked optional. This updates publish-maven.gradle to find all the artifacts and mark them as optional as apposed to the first entry.	12 years ago
Chris Beams	963b4e49a9	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
Chris Beams	b6cb514d38	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