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
In the 2.0.0.M5 release bundlor successfully created manifests at
target/classes/META-INF/MANIFEST.MF within each subproject directory,
however they were not actually picked up by the maven-jar-plugin when
creating each archive. The samples parent pom has now been configured
to explictly specify the 'manifestFile' and refer to the bundlor-generated
manifest.
Additionally, the spring-integration-samples/pom.xml was updated with
a similar configuration for the maven-jar-plugin, but in this case the
spring-integration-parent/pom.xml configuration is being overwritten.
The samples projects do not use Bundlor, and thus there is no generated
manifest in the location mentioned above. This causes the maven-jar-plugin
to error out for the samples, and as a workaround there is now a zero-length
file at spring-integration-samples/src/main/resources/META-INF/MANIFEST.MF
that samples refer to during jar/war packaging. Ugly, but effective.
* 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
* normalizing version placeholders to use ${groupId}.version as a naming convention e.g.: 'org.springframework.version'
* added properties to parent pom <properties/> section
* spaces -> tabs
* removed empty newlines in poms (favor comments instead of newlines)
* gave all samples nice <name>s
* included ws-inbound-gateway in the samples parent pom <modules> section
* samples now try to run any **/*Tests.java, as per our general conventions
Updated log4j.xml files to quell debug/info output
Moved src/test/resources/**/* -> src/main/resources/**/* for the time being to fix the jdbc build
Eliminated several System.out.println calls in tests
