00a86c3722
Split packages are a well-known anti-pattern for OSGi and a blocker for Eclipse Virgo (which prevents split packages being accessed via its Import-Library construct). Split packages are also unhelpful with a traditional linear classpath as a split package name does not uniquely identify the Spring framework JAR from which it came, thus complicating problem diagnosis and maintenance. Juergen Hoeller supports this position in the following comment in SPR-9990: >FWIW, I generally find split packages a bad practice, even without >OSGi in the mix. For the Spring Framework codebase, I consider a >split-package arrangement a design accident that we want to detect >in any case - and that we're willing to fix if it happened. > >I'm actually equally concerned about the source perspective: After >all, we want a package to be comprehensible from a single glance >at the project, not requiring the developer to jump into several >source modules to understand the overall layout of a package. Split packages have crept into Spring framework twice in recent months - see SPR-9811 and SPR-9988. Currently, they are only detected once the Spring framework has been converted to OSGi bundles and these bundles have been tested with Eclipse Virgo. This commit adds a build-time check for split packages to the Spring framework build. Issue: SPR-9990 Conflicts: build.gradle
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
See downloading Spring artifacts for Maven repository information. Unable to use Maven or other transitive dependency management tools? See building a distribution with dependencies.
Documentation
See the current Javadoc and reference docs.
Getting support
Check out the Spring forums and the spring and spring-mvc tags on Stack Overflow. Commercial support is available too.
Issue Tracking
Report issues via the Spring Framework JIRA. Understand our issue management process by reading about the lifecycle of an issue. Think you've found a bug? Please consider submitting a reproduction project via the spring-framework-issues GitHub repository. The readme there provides simple step-by-step instructions.
Building from source
The Spring Framework uses a Gradle-based build system. In the instructions
below, ./gradlew is invoked from the root of the source tree and serves as
a cross-platform, self-contained bootstrap mechanism for the build. The only
prerequisites are Git and JDK 1.7+.
check out sources
git clone git://github.com/SpringSource/spring-framework.git
compile and test, build all jars, distribution zips and docs
./gradlew build
install all spring-* jars into your local Maven cache
./gradlew install
import sources into your IDE
Run ./import-into-eclipse.sh or read import-into-idea.md as appropriate.
... and discover more commands with ./gradlew tasks. See also the Gradle
build and release FAQ.
Contributing
Pull requests are welcome; see the contributor guidelines for details.
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.