These manual updates are no longer required as of recent changes
to buildSrc and its generatePom tasks. Now, when the project
version is changed in gradle.properties, generatePom will notice
and fire. Previously, generatePom did not consider gradle.properties
as input for incremental build purposes; now it does.
For ease of use by those (a) more familiar with Maven or (b) relying
on m2eclipse support within Eclipse/STS, generated poms are now checked
in. Changes to these files will be overwritted on subsequent gradle
builds.
Any changes to project dependencies should first be reflected in
build.gradle; then run `gradle generatePom` or simply `gradle build`
to see the change reflected in the pom(s).
Note that org.springframework.integration.ip.tcp.TcpInboundGatewayTests
currently fails when running `mvn clean test` from the root. This
problem does not manifest when running `gradle clean test`. The latter
is what's most important; Gary has been contacted to take a look at the
former.
Issues resolved:
INT-1609, INT-1610, INT-1611
POMs removed in favor of Gradle build. pom.xml added to .gitignore
to accommodate future generation of source-level poms for those who
wish to use m2eclipse tooling in STS (to come in a later commit)
- 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.
