b6cb514d38
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
|
||
|---|---|---|
| .wrapper | ||
| org.springframework.aop | ||
| org.springframework.asm | ||
| org.springframework.aspects | ||
| org.springframework.beans | ||
| org.springframework.context | ||
| org.springframework.context.support | ||
| org.springframework.core | ||
| org.springframework.expression | ||
| org.springframework.instrument | ||
| org.springframework.instrument.tomcat | ||
| org.springframework.jdbc | ||
| org.springframework.jms | ||
| org.springframework.orm | ||
| org.springframework.oxm | ||
| org.springframework.test | ||
| org.springframework.transaction | ||
| org.springframework.web | ||
| org.springframework.web.portlet | ||
| org.springframework.web.servlet | ||
| org.springframework.web.struts | ||
| src | ||
| .gitignore | ||
| README.md | ||
| build.gradle | ||
| eclipse-code-formatter.xml | ||
| gradle.properties | ||
| gradlew | ||
| gradlew.bat | ||
| publish-maven.gradle | ||
| settings.gradle | ||
| spring-framework.ipr | ||
| spring-framework.psf | ||
README.md
Spring Framework
The Spring Framework provides a comprehensive programming and configuration model for modern Java-based enterprise applications - on any kind of deployment platform. A key element of Spring is infrastructural support at the application level: Spring focuses on the "plumbing" of enterprise applications so that teams can focus on application-level business logic, without unnecessary ties to specific deployment environments.
The framework also serves as the foundation for Spring Integration, Spring Batch and the rest of the Spring family of projects. Browse the repositories under the SpringSource organization on GitHub for a full list.
.NET and Python variants are available as well.
Downloading artifacts
Instructions on downloading Spring artifacts via Maven and other build systems are available via the project wiki.
Documentation
See the current Javadoc and Reference docs.
Getting support
Check out the Spring forums and the Spring tag on StackOverflow. Commercial support is available too.
Issue Tracking
Spring's JIRA issue tracker can be found here. Think you've found a bug? Please consider submitting a reproduction project via the spring-framework-issues repository. The readme provides simple step-by-step instructions.
Building from source
Instructions on building Spring from source are available via the project wiki.
Contributing
Pull requests are welcome; you'll be asked to sign our contributor license agreement (CLA). Trivial changes like typo fixes are especially appreciated (just fork and edit!). For larger changes, please search through JIRA for similiar issues, creating a new one if necessary, and discuss your ideas with the Spring team.
Staying in touch
Follow @springframework and its team members on Twitter. In-depth articles can be found at the SpringSource team blog, and releases are announced via our news feed.
License
The Spring Framework is released under version 2.0 of the Apache License.