We are very excited that the Spring-Core framework has moved to Gradle. A number of other Spring projects have migrated to Gradle before. Yet having the core of such an important Java enterprise technology to be built with Gradle is very special. Many thanks to our friends at SpringSource, particularly Chris Beams, for their invaluable feedback to make Gradle a better tool. SpringSource has always been a beacon for me in regard to software craftsmanship. This move means a lot to us.
The 2.9.0M2 STS milestone is available with an improved Gradle plugin for Eclipse.
Version 0.4.1 of the GradleFx Flex plugin is available.
Benjamin Muschko released a version 0.2 of the Gradle Java2HTML plugin.
Andrew Oberstar published a Gradle Git and Github plugin. It is based on an idea from Peter Ledbrook who wrote a couple of Gradle tasks for working with Git. They use pure Java, so no dependencies on the git commands.
Gradle Posts Alexej Bondarenko blogged about setting up Lift with Gradle (in German).
Eveoh blogged about using Gradle with the Google Web Toolkit.
Michael Prader followed up on an earlier posting on how to build jaxb classes with Gradle from an XML Schema. Michael also blogged about creating batch and assembly libraries.
Gunnar Hillert set up the Sonar metrics page for Spring integration The metrics are created by the Gradle Sonar plugin.
A reminder from Sonatype. To take away pressure from Maven Central and preserve a good quality of service, use a repository manager like Artifactory or Nexus as a proxy. Our thanks to Sonatype for providing the Maven Central service.
Scott Andrews wrote a quick and dirty Gradle task for deploying Cloud Foundry.
In the Gradle build itself there is now a basic Gradle task for uploading to Amazon S3. Anyone wants to turn this into a Gradle S3 plugin? Ping us in the forums.
##Gradle Development (by Adam Murdoch)
This week we made a Gradle 1.0-milestone-8 snapshot available. Please give this snapshot a try.
We also have put together our plan for the Gradle 1.0 release. Please have a read and let us know what you think.
Some development highlights this week:
- Added new PMD, FindBugs, JDepend code quality plugins. Thanks to Andrew Oberstar for these excellent contributions. * Added an initial reporting DSL. For now, this is only used by the code plugins, but over time we will wire in the test and project reports. This DSL is the starting point for some nice reporting features in Gradle to come in the future, such as an equivalent of the maven site plugin and other goodies. * Added a new backend for the Java Compile task type, which bolts directly onto the Java compiler APIs rather than using the Ant javac task. This backend is quite a bit faster than the Ant based backend, doesn’t have any command-line length limitations on windows, and will allow us to later add all kinds of interesting features, such as real incremental compilation, and more accurate classpath change detection. And this means faster builds. At the moment, the new backend is disabled by default. * You can now specify the java home that your build should use without needing to mess with environment variables. * Better feedback when things go wrong with the daemon, such as the daemon failing to start or crashing. * Many new additions to the user guide, covering the tooling api, daemon, troubleshooting, the wrapper and dependency caching. * Lots of bug fixes, big and small, in various areas.
This week we plan to release 1.0-milestone-8, then finish up the final features before Gradle 1.0:
- Enable the new compile task backend by default. This will include a nice reuse feature, where Gradle will attempt to shared forked compile processes across multiple compile tasks. This way you get the isolation and cross-compilation capabilities of forking compilation, with the performance of non-forking compilation. * Wire up the ‘gradle’ and ‘gradlew’ commands to honor the new ‘org.gradle.jvmargs’ and ‘org.gradle.javahome’ properties, which are already used by the daemon and the tooling API. This way, you will have a consistent way to control the build environment, in a configuration file that you can check into source control.