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…
This release includes: This is also the first release since our move to GitHub and using our new Gradle build. A special thanks to the authors of the many pull requests submitted and merged during 3.2 M1! Keep them coming!
Today we're happy to announce that the Spring Framework has moved to GitHub! As you've probably noticed, nearly every other Spring project has already made the move, and those that haven't will soon. Git helps us with many of the challenges of managing a large codebase like the Spring Framework, but what's most exciting is what GitHub means for the Spring community. Many readers will already know the virtues of watching and forking repositories, pull requests, forking and editing, and the many other features that GitHub adds to the already excellent world of Git. If you're new to this stuff…
As Juergen mentioned in his post yesterday, and as I've mentioned in my previous posts on 3.1 M1, one of the major themes of Spring 3.1 is completing our vision for code-based configuration in Spring. We think a modern enterprise Java application should have a choice between Java and XML as first class options for its configuration. In this post we'll see how Spring 3.1 M2 helps make this a reality. Note that although Java-based configuration has been available since Spring 3.0, with this release it is now on par with many more of the XML-based features that have been developed over the…
UPDATE: The FeatureSpecification functionality described in this blog post was removed in Spring Framework 3.1 M2 in favor of @Enable* annotations. See the 3.1 M2 announcement for more information. Earlier in this series I touched on how the new @Profile annotation can be used in conjunction with @Configuration classes to take advantage of Spring's bean definition profiles. Today, we'll look at an entirely new addition to the code-based configuration landscape in Spring 3.1: FeatureSpecification classes and their related support. I've put together a sample project to accompany this post…
In the first two posts of this series, I described the bean definition profiles feature, and how it relates to the Environment abstraction new in Spring 3.1 M1. Today we'll take a look at a second aspect of the Environment -- how it helps simplify the concern of configuration property management. Spring's Environment abstraction provides search operations over a configurable hierarchy of property sources. To explain fully, consider the following: In the snippet above, we see a high-level way of asking Spring whether the 'foo' property is defined for the current environment. To answer this…
In my earlier post announcing Spring 3.1 M1, I discussed the new bean definition profiles feature as applied when using Spring XML to configure the container. Today we'll introduce the new @Profile annotation and see how this same feature can be applied when using @Configuration classes instead of XML. Along the way we'll cover some best practices for designing @Configuration classes. For those unfamiliar with @Configuration classes, you can think of them as a pure-Java equivalent to Spring XML files. We've blogged about this featureset before, and the reference…
