The docbook-gradle-plugin has been custom-developed specifically to
handle Spring projects. It is highly opinionated, and not terribly
configurable in its current form. Sources and documentation are
available via the 'gradle-plugins' github repository at
https://github.com/cbeams/gradle-plugins
Note that this repository may soon move locations to the SpringSource
GitHub organization, in which case the url will be
https://github.com/SpringSource/gradle-plugins
In any case, the build plans for these plugins can be found at
https://build.springsource.org/browse/GRADLEPLUGINS
This change eliminates the spring-framework-reference subproject, moving
these sources into the root project's own src directory.
This makes sense because the reference docs span all submodules, and
also because api Javadoc is created at the root project level as well.
This means that both api and reference documentation output will now
reside in the root project's 'build' directory. This is more consistent
and easy to discover.
This commit eliminates the 'integration-tests' subproject in favor of
managing these sources under the root project's own 'src' directory.
This helps to avoid special-case handling for integration-tests in the
Gradle build, e.g. avoiding publication of jars to Artifactory /
Maven Central.
It is also semantically more correct. This is not a Spring Framework
subproject so much as it is a collection of integration tests that
span functionality across many subprojects. In this way, it makes
sense to place them directly under the root project.
Issue: SPR-8116
- Use recent Gradle 1.0-milestone-8 snapshot
- Add initial cut of build.gradle able to compile/test all modules
- Update .gitignore
- Generate Gradle wrapper scripts
- Remove all Eclipse metadata files
- Temporarily @Ignore tests that do not pass under Gradle
Previously flash attributes were automatically merged into the
model of annotated controllers only. This change extends the same
benefit to ParameterizableView- and UrlFilenameViewController,
both of which merely select a view without user controller logic
and (the views) would otherwise not have access to the flash
attributes.
When checking for an exact match of Accept header media types
additional parameters such as quality need to be excluded.
For example "*/*" matches "*/*;q=0.9".
- Eliminate trailing whitespace
- Update long method signatures to follow framework whitespace
conventions
Based on the following search,
$ git grep -A3 '^.public .* .*([^\{;]*$' */src/main
the strong convention throughout the framework when dealing with
methods having long signatures (i.e. many parameters) is to break
immediately after the opening paren, indent two tabs deeper and break
lines around 90 characters as necessary. Such signatures should also
be followed by a newline after the opening curly brace to break
things up visually.
The files edited in this commit had a particularly different style of
intenting arguments to align with each other vertically, but the
alignment only worked if one's tabstop is set at four spaces.
When viewed at a different tabstop value, the effect is is jarring,
both in that it is misaligned and significantly different from most
of the framework. The convention described above reads well at any
tabstop value.
Before this change, flash attributes could only be added if via
RedirectAttributes.addFlashAttribute(..) if the method returned
a view name or a View instance. With this change, the above is
supported with a ModelAndView return value as well.
Prior to this change, the spring-cache XSD allowed a 'key-generator'
attribute, but it was not actually parsed by AnnotationDrivenCacheBDP.
This commit adds the parsing logic as originally intended and the test
to prove it.
Issue: SPR-8939
Prior to this change, the caching reference docs referred to
'root.params', whereas the actual naming should be 'root.args'. This
naming was also reflected in the "#p" syntax for specifying method args.
This change updates the documentation to refer to 'root.args' properly
and also adds "#a" syntax for specifying method arguments more
intuitively. Note that "#p" syntax remains in place as an alias for
backward compatibility.
Issue: SPR-8938
Reconciled all 3.1.1 dev against 3.1.x and master (3.2.x) branches.
From this point forward, all 3.1.1 dev should happen directly against
3.1.x, and we will periodically merge those changes into master.
Note that when these merges take place, there will be a conflict
among any files containing version numbers, such as build.properties
and pom files. Use `git rerere` to record the conflict resolution
strategy for future merges, avoiding redundant work.
$ git config --global rerere.enabled 1
$ git checkout master
$ git merge 3.1.x # conflicts
$ git checkout master # take master version of all affected files
$ git commit # conflict resolution strategy is remembered
See http://progit.org/2010/03/08/rerere.html
Conflicts:
build.properties
org.springframework.aop/pom.xml
org.springframework.asm/pom.xml
org.springframework.aspects/pom.xml
org.springframework.beans/pom.xml
org.springframework.context.support/pom.xml
org.springframework.context/pom.xml
org.springframework.core/pom.xml
org.springframework.expression/pom.xml
org.springframework.instrument.tomcat/pom.xml
org.springframework.instrument/pom.xml
org.springframework.integration-tests/pom.xml
org.springframework.jdbc/pom.xml
org.springframework.jms/pom.xml
org.springframework.orm/pom.xml
org.springframework.oxm/pom.xml
org.springframework.spring-library/pom.xml
org.springframework.spring-parent/pom.xml
org.springframework.test/pom.xml
org.springframework.transaction/pom.xml
org.springframework.web.portlet/pom.xml
org.springframework.web.servlet/pom.xml
org.springframework.web.struts/pom.xml
org.springframework.web/pom.xml
Chris Beams
Arjen Poutsma
Arjen Poutsma
Rossen Stoyanchev
Chris Beams
Juergen Hoeller
Costin Leau