VMware offers training and certification to turbo-charge your progress.Learn more
There are benefits for project committers and Spring users alike following the move to Git and GitHub. GitHub has an excellent UI for code browsing, history of changes, and commit comments. And with the amazing number of open source projects already hosted at GitHub, this means that you're using one well-understood UI and that you already know how to browse source control, examine recent changes and so on. But GitHub's real power is in the way it encourages and supports community contribution. This point is discussed further in the "contribution process" section below.
For now, check out the SpringSource organization at GitHub if you haven't already; you'll see we've been busy as usual.
GA versions of Spring artifacts will continue to be published to Maven Central as always, but repo.springsource.org replaces our previous infrastructure at maven.springframework.org with a much more powerful solution -- proper UI and search functionality, deep integration with our CI server at build.springsource.org, and many other features that help project teams streamline their release processes.
The upshot for Spring users is that the SpringSource repository is one-stop shopping for all your Spring dependency needs.
If you have maven.springframework.org URLs in your build scripts, they will continue working indefinitely* but these URLs should be considered "deprecated" in favor of repo.springsource.org going forward.
Further explanation and instructions for use can be found at the downloading Spring artifacts page in the spring-framework GitHub wiki. The SpringSource repository FAQ should be able to answer any questions that come up. If not, let us know!
A big thanks to the team at JFrog -- the makers of Artifactory -- for working with us to make this happen. Switching repository infrastructure across so many busy projects begs for disaster, but with their help it's been smooth. And thanks also to the team at Sonatype for their consistently prompt and helpful responses to our needs around Maven Central.
Gradle has many innovative features that make it a pleasure to use, like an incremental build system that significantly cuts down on build times, minimalistic command-line output that shows you only what you need to know, and a concise syntax that makes it possible to build a large codebase like the Spring Framework with a remarkably small and readable build script.
For Spring users, the system used to build Spring projects may not seem to matter much. Indeed, just like most Linux users don't compile their own kernels, most Spring users never build Spring artifacts from source. But like any good open source project, some do. Whether simply to understand Spring better or to make changes and contribute back to the project, the number of people that build Spring from source is growing, thanks in part to the way that Gradle makes doing so quite trivial. One of Gradle's great features is the so-called Gradle Wrapper which is essentially a platform-native shell script that downloads and installs the exact Gradle version used by a project. This means that building a Gradle-based Spring project from source is literally as simple as typing:
$ git clone https://github.com/SpringSource/spring-framework.git $ cd spring-framework $ ./gradlew build
As you can see, the 'gradlew' script there is checked into project source control. So as the version of Gradle used to build the project changes, the wrapper stays up to date and new versions of Gradle are downloaded automatically when necessary. This means never hearing "the build is broken" only to find out that two different versions of the build tool were being used. And it means that Spring projects can immediately keep up to date with the latest changes to Gradle without risking breaking other committers' and contributors' builds.
Check out the complete (but still very simple) instructions in the building from source section of the Spring Framework readme. Compare the 100 words you see there to the 1,500-word blog post on Building Spring 3 that I wrote a few years ago. I hope you'll find it's quite an improvement. Give it a try -- you might even like it:
The Gradle team have been a tremendous help in this process -- Spring projects have regularly pressed Gradle to the limits and challenged the team with requirements over the last couple of years, and the Gradle team have been nothing but responsive and helpful. Many of the Spring projects are certainly better off today for Gradle, and we hope that Gradle itself is at least a little better for the challenges we threw at it. Congratulations to the team on their 1.0!
Since the Spring Framework moved to GitHub at the end of 2011 and to the time of this writing in June 2012, the project has received just over 100 pull requests. Not every pull request gets in. The outcome depends on the review process, but nevertheless many of these contributions have made their way in, sometimes after significant discussion and refinement. We've put together a contributor guidelines document based on what we've learned over this period; give it a read if you have something you'd like to give back to the framework. This is a great way of getting your issue to the front of the line. We naturally give a bit of priority to users who take the time to put together a high-quality contribution. Thanks to all those who have done so already, and thanks in advance to future contributors!
We're glad to announce with this blog post the new spring-framework-contrib mailing list hosted at Google Groups. This list is specifically dedicated to developers who want to contribute code to the Spring Framework project. It's a place where you can talk directly with the committers and other contributors about your ideas -- before or while writing code. We encourage anyone thinking about putting together a pull request to join the group and discuss your ideas with us there.
You'll also notice a number of smaller changes around the Spring Framework JIRA project: A revised set of components, simplified issue creation screen and a number of other tweaks designed to make issue reporting as useful and painless as possible.
There's another Q&A resource we'd like to make sure everyone in the Spring community is aware of. As you probably know, over the last few years Stack Overflow has become an extremely popular resource for programming Q&A. And Spring-related Q&A has been no exception to the phenomenon. If you visit http://stackoverflow.com/tags and type in "spring", you'll see there are many Spring-related tags already there, with spring and spring-mvc being the most popular. I and other members of the Spring team have often been impressed by the quality of conversation at Stack Overflow, and we're very happy to see and thank everyone providing great answers.
A tag-based system like the one at Stack Overflow is by nature a little harder to define than the strict project-oriented categories offered by the Spring Forums, but we'd like to suggest that if you have Spring Framework-specific questions, please use the 'spring' or 'spring-mvc' tags as appropriate. If you have Spring Integration-related questions, use the spring-integration tag and so on. It's pretty self-explanatory, really.
** Individual Spring project teams are free to choose the build tool that suits them best. This means that while many projects have moved to Gradle, it's predictable that other projects will stick with Maven.