FAQ
No. Certain open-source projects managed by SpringSource have determined that Gradle best suits their specific needs, and therefore have ported their builds to use Gradle. Most have chosen to use this 'shared Gradle sources' project for convenience and consistency.
It has always been the case that SpringSource projects have used a variety of build systems and this will continue into the future. For some teams, Ant and Ivy are the right choice; for others, Maven; for others still, Gradle. We encourage project teams to do their own analysis of build frameworks and choose the one that suits their team and applications best.
This project serves the needs of SpringSource-managed open-source projects that use Gradle. It is not intended for use as a general purpose build system. If you're reading this as an end user and are interested in using Gradle to build your own projects, see the Gradle documentation. With that said, you may nevertheless find it useful to see how the sources in this project have been structured. We hope you find it useful to look around.
See Spring projects built with Gradle.
There is no dedicated Gradle tooling in Eclipse or STS at this time. Gradle ships with its own Swing UI, and IntelliJ IDEA integrates it directly.
However, Gradle itself ships with Eclipse and IDEA plugins that generate necessary metadata for these two IDEs. See more at manage IDE metadata.
Yes. The Gradle maven plugin introduces tasks to the build lifecycle that generate Maven pom files based on gradle metadata. For example, gradle install installs artifacts to the local m2 cache just as with mvn install. gradle uploadArchives deploys artifacts to remote Maven repositories, much like mvn deploy.
Gradle provides a POM customization API as well, for cases where generated artifacts need to be tweaked.
The shared sources in this project configure Gradle's Maven tooling to meet the needs of deploying to SpringSource Maven repositories, as well as synchronizing with Maven Central. See create your project for information on properly setting up Maven publication.
While installing Gradle natively is always an option, you actually do not need to. Spring projects are encouraged to include os-native shell scripts generated by the Gradle Wrapper. On Windows, this file is gradlew.bat; on unx, use the gradlew shell script. These scripts bootstrap Gradle including any necessary downloads, so building should work out of the box with $PROJECT_ROOT/gradlew build. On unx platforms, you may want to set
up an alias, e.g., alias gradle=$PROJECT_ROOT/gradlew.
Currently, the shared Gradle wrapper configuration uses Gradle 0.9-rc-3. You may install this locally if you wish, per the installation instructions on the Gradle homepage.
Alternatively, OS X users may wish to install Homebrew and use brew install gradle --HEAD (may or may not be exactly the same version used by the wrapper).
Yes. You can manage OSGi metadata using template.mf files and the Gradle Bundlor plugin.
No. Enterprise Bundle Repository (EBR) publication happens via JIRA requests. See EBR-683 for one such request. This process is manual because of EBR requirements on Ivy metadata. In the future and if demand merits, the shared sources may be enhanced to generate this metadata and automate EBR publication.
Git submodules are a reasonable solution to sharing build sources in lieu of a more formal set of plugins. Over time, as sources stabilize and Gradle's own plugin infrastructure becomes more advanced, the submodule approach may be replaced.
In any case, build.gradle scripts in the root of Spring projects will remain largely unchanged. The shared Gradle sources are designed to support writing completely declarative build scripts. Whether plugins live in a shared buildSrc git submodule, or are downloaded from a repository, build scripts will change very little.
Furthermore, git submodules allow for easy access to build sources, and thus transparency for the build system. While standard use cases should not require editing shared build sources, when it is required it is convenient to do so.
Git submodules work well enough, but do have some quirks. See git submodule essentials for details.
See support optional and provided dependencies
This is probably due to docbook processing being (a) memory intensive and (b) not (yet) forked. See GRADLE-29.
In the meantime, simply run gradle with GRADLE_OPTS='-XX:MaxPermSize=1024m -Xmx1024m' to be safe.
For example:
GRADLE_OPTS='-XX:MaxPermSize=1024m -Xmx1024m' $PROJECT_ROOT/gradlew build
For un*x users, it is recommended to add GRADLE_OPTS to your default gradle alias configuration:
alias gradle=GRADLE_OPTS='-XX:MaxPermSize=1024m -Xmx1024m' $PROJECT_ROOT/gradlew build
In any of the following ways:
- Navigate to the list of pages for this wiki, where you'll find an RSS feed link.
- Clone the wiki git repository
- "Watch" this wiki repository via GitHub, and use your personalized GitHub RSS feed