Previous to this change, symlinks at
http://static.springsource.org/spring-integration/docs had to be
maintained by hand. The build now automatically updates:
* 'Wildcard' symlinks (e.g.: 2.0.x -> 2.0.0.RC1) if the release type
is anything other than SNAPSHOT.
* 'Latest GA' symlink (e.g.: latest-ga -> 1.0.3.RELEASE) if the release
type is RELEASE.
Also, deletion of the docs zip archive is now consolidated into the
same 'sshexec' command as the unzipping itself. Unzipping is now
done with -q (quiet) to cut down on output noise.
The spring-integration/docs/ directory on static.springframework.org
has sticky group-write permissions. unzip is now invoked with the '-K'
flag to ensure that newly created directories respect these permissions.
This is important to ensure that different (ssh) users can release the
project without running into permissions errors. Without -K, the unzip
command will preserve whatever permissions were present on the files and
directories at the time of archiving, and this usually means that
group-write is off.
Of course, all this assumes that users doing releases are part of the same
group - 'springorg' in this case.
Prior to this change, a graphical Ivy-branded authentication dialog was
appearing when attepmting to scp the docs zip file to
static.springframework.org. This was because the 'keyFile' property
of the uploadArchives task was not being set. It is being set correctly
now, based on the value of the 'sshPrivateKey' project property that
must be set in gradle.properties. This value has been set on the
build server's gradle.properties file, such that the INT-NIGHTLY build
can succeed in pushing docs during the build.
Bamboo CI server checks out into a directory named
'checkout', instead of a directory named 'spring-integration'
as would be expected. Root project naming defaults
to the name of the containing directory, so it becomes
important to be explicit.
Generate poms from Gradle metadata with
`gradle generatePom`
This will create a root pom with a <modules> section as well as a pom
for every individual module.
These poms are suitable for use with m2eclipse (e.g., File->Import->
Existing Maven project), or at the command line for basic build goals
such as `mvn test`.
These poms are not capable of producing distribution artifacts or
deployment of artifacts.
pom.xml and target will remain in .gitignore as these artifacts are
transient and for developer convenience only.
