Author: sebb
Date: Mon Apr 5 21:00:24 2010
New Revision: 930959
URL: http://svn.apache.org/viewvc?rev=930959&view=rev
Log:
Expand description of "svn cp URL1 URL2" method
Standardise on Maven, Ant, Javadoc for the names of the tools
Modified:
commons/proper/commons-site/trunk/src/site/xdoc/releases/prepare.xml
Modified: commons/proper/commons-site/trunk/src/site/xdoc/releases/prepare.xml
URL:
http://svn.apache.org/viewvc/commons/proper/commons-site/trunk/src/site/xdoc/releases/prepare.xml?rev=930959&r1=930958&r2=930959&view=diff
==============================================================================
--- commons/proper/commons-site/trunk/src/site/xdoc/releases/prepare.xml
(original)
+++ commons/proper/commons-site/trunk/src/site/xdoc/releases/prepare.xml Mon
Apr 5 21:00:24 2010
@@ -41,7 +41,7 @@
Commons components are expected to use Maven to build the project website.
Components
may choose to use either Maven or Ant to build the actual jar and tar/zip
files to be distributed,
although it is recommended that Maven be used for this. Both approaches
are covered
- below. The version of maven used is assumed to be Maven 2 throughout. At
a minimum, Commons
+ below. The version of Maven used is assumed to be Maven 2 throughout. At
a minimum, Commons
releases <strong>must</strong> include full source distributions packaged
in tar and zip
archives.
</p>
@@ -89,7 +89,15 @@
Note that the "svn update" step is necessary in order to ensure that the
directory being
copied does not have a mix of files at various revisions; even if the
files haven't changed
since the last svn update this can cause "svn log -v" on the new
directory to report files as
- having been (R)eplaced. Alternatively, use "svn cp URL1 URL2" which will
copy files
+ having been (R)eplaced.
+ </p>
+ <p>Alternatively, use "svn cp URLsrc URLtag"</p>
+ <pre>
+ svn cp -m "Creating foo-1.2-release branch" \
+ https://svn.apache.org/repos/asf/commons/proper/foo/trunk \
+
https://svn.apache.org/repos/asf/commons/proper/foo/branches/foo-1.2-release
+ </pre>
+ <p>which will copy files
internally within the repository without using the local working copy:
this always ensures
a clean copy is made.
</p>
@@ -104,7 +112,7 @@
that the current level of compatibility is suitable for the proposed
version number.
Check the current level of compatibility in the code. Tools like
<a href='http://clirr.sourceforge.net'>Clirr</a> and
- <a href='http://www.jdiff.org'>JDiff</a> are very useful. Both support ant
and maven.
+ <a href='http://www.jdiff.org'>JDiff</a> are very useful. Both support Ant
and Maven.
</p>
</subsection>
<subsection name='Check Javadocs And Code Style'>
@@ -113,8 +121,8 @@
Compatibility reports produced in the last section may prove helpful.
</p>
<p>
- Ensure no errors or warnings are reported by the javadoc tool.
- Check that the javadocs have the correct version number.
+ Ensure no errors or warnings are reported by the Javadoc tool.
+ Check that the Javadocs have the correct version number.
</p>
<p>
If the component uses checkstyle, findbugs or PMD tools, examine the
reports and fix all
@@ -123,7 +131,7 @@
</subsection>
<subsection name='Configure the Build to Generate a Complete Set of
Release Artifacts'>
<p>
- For builds using maven, the contents of the source and binary
distributions are configured
+ For builds using Maven, the contents of the source and binary
distributions are configured
in assembly descriptors. By convention, these are stored in
src/main/assembly and named
src.xml and bin.xml, respectively. Names and locations for these files
are specified in
the maven-assembly-plugin configuration in the pom. Make sure that all
(and only) files
@@ -134,7 +142,7 @@
</p>
<p>
Update the version numbers in pom.xml and build.xml to the new release
version, in this example, 1.2.
- For maven builds, make sure that the build properties are properly set.
Review the <code>properties</code>
+ For Maven builds, make sure that the build properties are properly set.
Review the <code>properties</code>
section of the pom:
<pre>
<properties>
@@ -157,11 +165,11 @@
svn commit -m "Updated download page in preparation for 1.2 release."
src/site/xdoc/download_foo.xml </pre>
</p>
<p>
- When using Ant, typically the Ant dist goal produces the source and
binary distributions. Included
- files are specified in the goal or subgoals and should be verified
similarly to above.
+ When using Ant, typically the Ant "dist" target produces the source and
binary distributions. Included
+ files are specified in the target or sub-targets and should be verified
similarly to above.
</p>
<p>
- Test the "Ant dist" or "mvn assembly:assembly" goal and inspect the
tars/zips and jars produced.
+ Test the "Ant dist" or "mvn assembly:assembly" command and inspect the
tars/zips and jars produced.
Verify that
<ol>
<li> "Ant dist" or "mvn site" succeeds from the unpacked source
distribution.</li>
@@ -216,8 +224,8 @@
target Java version for the component.
</p>
<p>
- Components that use the maven changes plugin and changes.xml to track
changes can generate
- a "starter" release notes document by supplying a custom Velocity
template to the maven
+ Components that use the Maven changes plugin and changes.xml to track
changes can generate
+ a "starter" release notes document by supplying a custom Velocity
template to the Maven
announcements plugin:
<pre>
mvn changes:announcement-generate
@@ -242,7 +250,7 @@
<p>
Different components have their own ways of creating the change log.
The most common, and recommended, way, is to record all significant
- changes in JIRA tickets and include entries in the maven change-log
+ changes in JIRA tickets and include entries in the Maven change-log
file, <code>changes.xml</code>.
Here's a way to get the information directly from svn if no change log
has been maintained for the component:
@@ -415,7 +423,7 @@
<subsection name='Create the Release Candidate Website'>
<p>
As well as putting up the source and binary distributions in your home
directory on people.apache.org for
- others to download and verify, the new website and maven artifacts
should also be published there. If using maven,
+ others to download and verify, the new website and Maven artifacts
should also be published there. If using Maven,
run "mvn site" locally, tar or zip the site in target/ and scp and unpack
the files
on people.apache.org.
</p>
@@ -426,10 +434,10 @@
<pre>
~/public_html/foo-1.2-RC1 (release notes, distribution tar/zips with
sigs and hashes)
~/public_html/foo-1.2-RC1/site (output of "mvn site" run from the RC tag)
- ~/public_html/foo-1.2-RC1/maven (maven pom, jars with sigs and hashes) </pre>
+ ~/public_html/foo-1.2-RC1/maven (Maven pom, jars with sigs and hashes) </pre>
The following script creates a local directory
<code>${release_path}</code> with the appropriate contents.
This directory can then be renamed, tarred/zipped and copied to your
public_html to be unpacked there. The
- script variable <code>${repo_path}</code> needs to point to the local
maven repository root for the component,
+ script variable <code>${repo_path}</code> needs to point to the local
Maven repository root for the component,
for example: <pre>
version=1.2
repo_path=~/.m2/repository/org/apache/commons/commons-foo/${version}
@@ -450,13 +458,13 @@
# Copy site
cp -R target/site ${release_path}
#
- # Copy maven artifacts
+ # Copy Maven artifacts
cp -R ${repo_path} ${release_path}
#
- # Rename maven directory
+ # Rename Maven directory
mv ${release_path}/${version} ${release_path}/maven
#
- # Delete tars/zips from maven subdirectory
+ # Delete tars/zips from Maven subdirectory
rm ${release_path}/maven/*.zip
rm ${release_path}/maven/*.zip*
rm ${release_path}/maven/*.gz
@@ -578,8 +586,8 @@
<subsection name="Javadoc">
<ul>
- <li>Ensure that the javadoc tool reports no warnings or errors.</li>
- <li>Ensure that all new classes and methods have appropriate @since
javadoc tags.</li>
+ <li>Ensure that the Javadoc tool reports no warnings or errors.</li>
+ <li>Ensure that all new classes and methods have appropriate @since
Javadoc tags.</li>
</ul>
</subsection>
@@ -604,7 +612,7 @@
</p>
<p><strong>Maven Build</strong></p>
<p>
- The maven build has been modified to include two <strong><i>non
standard</i></strong> attributes
+ The Maven build has been modified to include two <strong><i>non
standard</i></strong> attributes
in the jar's manifest to indicate the <code>maven.compile.source</code>
and
<code>maven.compile.target</code> properties used to create the jar. This
serves two purposes:
<ul>
