- Convert spaces to tabs on -ftp/pom.xml
- Normalize multi-line comments to fit the following style:
<!--
depend explicitly on 2.0 in order to pick up the new
release:update-versions goal
-->
- Revert some of the formatting that the Maven release:update-versions
goal forced on us. After it failed to perform its duties during the M7
release, it appears we will not be using it anymore.
The following commands now upload zips to dist.springframework.org:
- `mvn -Pmilestone deploy`
- `mvn -Prelease deploy`
The following do not:
- `mvn -Psnapshot deploy`
- `mvn -Pstaging deploy`
Use one of the following as appropriate when deploying the project:
* mvn deploy -Psnapshot
* mvn deploy -Pmilestone
* mvn deploy -Prelease
These profiles ensure that artifacts are uploaded to the right
repositories without requiring the buildmaster to change
<deploymentManagement> information manually.
- Upgrade to version 2.0 of the maven-release-plugin in order to
get the new 'update-versions' goal, which allows for doing nothing
other than updating pom versions - no tagging, no checkins, etc.
- Accommodate idiosyncracies of the plugin. When running for the first
time, it became clear that update-versions not only updates versions
as advertised, but also formats certain elements of the pom.
Committing just those format changes now so that future actual version
updates will not have to deal with this uninvited 'help'.
- How to run the command:
mvn --batch-mode release:update-versions -DdevelopmentVersion=2.0.0.M7
This will edit the <version> elements in the poms of the projects listed
in the root pom's <modules> section.
Upon updating to 3.0.4 the build fails with SpEL error code EL1004E when
executing test method shouldFindSimpleAggregatorMethodWithArray().
Reverting for now, but SPR-7519 has been created for tracking what
appears to be a minor SpEL regression.
- template.mf files now declare range [3.0.3, 4.0.0) for all Spring dependencies
- pom.xml files reverted to dependence on 3.0.3.RELEASE
-Prelease was inadvertently causing docbook generation to happen after
zip distribution packaging. Reasons for this are unclear, but given
that it was discovered in the middle of a release, the path of least
resistence is simply to revert the functionality and move on.
updated pom to emit compiler warnings so that any new ones become obvious
added serialVersionUID to classes that could reasonably need to be serialized (GenericMessage, MessageHeaders, etc)
@SuppressWarnings("serial") on all others
@SuppressWarnings("unused") on private static classes used as spring beans for testing (their methods never get called from java)
eliminated all redundant casting
introducted generics metadata where raw types were still being used
changed public API on several FactoryBeans (by adding <Type> information to 'implements FactoryBean' clause)
@Ignore'd SimpleTcpNetOutboundGatewayTests#testOutboundClose() to avoid failure; this failure is correlated to the module name change, but hard to understand how it would be caused by it
* incremental progress on getting docbkx working
- downgraded docbook 4.5 -> 4.4 because of "URI is not file" errors (`find src/docbkx/*.xml | xargs grep -l '4\.5' | xargs perl -p -i -e 's/4\.5/4.4/g'`)
- eliminated spring-integration-reference in favor of idiomatic src/docbkx under project root
- using xsl from spring-ws to get things working. need to figure out how to integrate previous xsl, however (it's still there), because the L&F is quite different now
- upgraded version of docbkx plugin to 2.0.9