[Db-derby Wiki] Update of "DerbySnapshotOrRelease" by JohnHEmbretsen

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by JohnHEmbretsen:
http://wiki.apache.org/db-derby/DerbySnapshotOrRelease

The comment on the change is:
Added section: Making a (private) Quick Build of Release Artifacts

------------------------------------------------------------------------------
  
  In essence a snapshot differs from a full release (feature, or bug fix release) in the following ways:
  
- 1. A snapshot is an alpha or beta distribution cut from the trunk, while a release (candidate) is supposed to be a full-fledged, upgradeable distribution, and likely cut from a branch. 
+  1. A snapshot is an alpha or beta distribution cut from the trunk, while a release (candidate) is supposed to be a full-fledged, upgradeable distribution, and likely cut from a branch. 
  
- 2. You don't have to polish the release notes for snapshots.
+  1. You don't have to polish the release notes for snapshots.
  
- 3. For snapshots, the vetting cycle is shorter and the community is willing to tolerate regressions and serious bugs in the interests of garnering early feedback. 
+  1. For snapshots, the vetting cycle is shorter and the community is willing to tolerate regressions and serious bugs in the interests of garnering early feedback. 
  
+  1. Snapshots don't necessarily include everything included in a full release, for example demos, plugins etc.
+ 
- 4. Snapshots are placed in a different location:
+  1. Snapshots are placed in a different location:
  
    It's a good idea, once the snapshot has appeared on the site, to announce to derby-dev and derby-user that the new snapshot has been posted so interested testers can grab it.
  
+ 
+ = Making a (private) Quick Build of Release Artifacts =
+ 
+ Sometimes it is useful for a Derby developer to build a private version of the release artifacts (archives), for example to verify modifications made to the structure of a specific release distribution (-bin, -lib, -lib-debug, -src, etc.). 
+ 
+ For example, when adding a new demo or changing which files gets included in certain subdirectories of a -bin distribution, reviewing generated release artifacts is often the only way to verify that modifications made to the build scripts are correct (of course, having a developer with knowledge of the build scripts and experience with the release building process review the patch thoroughly would help as well).
+ 
+ Note that this section describes only a small subset of the steps needed to build a real Apache Derby release. The generated artifacts are '''''only suitable for private testing purposes only'''''.
+  * the development community has not been involved
+  * version numbers are probably incorrect
+  * release notes are wrong, or not included at all
+  * jars are not signed
+  * etc. etc.
+ 
+ To build a set of release artifacts that are suitable for reviewing the file structure of a release, among other things, do the following steps (extraced from the full release procedure description above):
+ 
+  1. Check out (or update) the source tree from which you want to build release artifacts, for example 
+    https://svn.apache.org/repos/asf/db/derby/code/trunk/ for the trunk
+ 
+  1. Make sure you are able to build the code jars the regular way, as described in [http://svn.apache.org/repos/asf/db/derby/code/trunk/BUILDING.txt BUILDING.txt]
+ 
+  1. Check out (or update) the corresponding documentation tree, for example 
+    https://svn.apache.org/repos/asf/db/derby/docs/trunk/ for trunk
+ 
+  1. Build the documentation (all) as described on the [http://db.apache.org/derby/manuals/dita.html web site]
+ 
+  1. Copy {{{tools/ant/properties/packaging.tmpl}}} to {{{tools/ant/properties/packaging.properties}}} and modify as necessary (see details above). The important thing here is to include a pointer to you doc build, for example:
+    {{{
+ docs.out=/export/home/tmp/user/docTrunk/trunk/out
+    }}}
+ 
+  1. Include the following in your {{{ant.properties}}} file (for 10.3 or newer), modified to suit your environment:
+    {{{
+ j14lib=/usr/local/java/jdk1.4/jre/lib
+ jdk16=/usr/local/java/jdk1.6.0
+ # If you want Java ME-support:
+ jsr169compile.classpath=/home/user/lib/cdc/jsr169.jar:/home/user/lib/cdc/btclasses.zip
+ #  May not be necessary (?):
+ relnotes.src.reports=/home/user/derby/relnotes-reports # empty directory
+    }}}
+ 
+  1. In the top-level directory of the source code tree, do:
+    {{{
+ # If you have built release artifacts or snapshots before, clean up. Also
+ # clean up jars and javadoc:
+ rm -rf jars javadoc snapshot                   # clean.
+ rm -rf tools/release/crlf/ tools/release/lf/   # clean more.
+ rm tools/release/maintversion.properties       # really clean.
+ rm tools/release/*.zip tools/release/*.tar.gz  # really,
+ rm tools/release/*.md5 tools/release/*.asc     # really clean
+ 
+ # In any case do this:
+ ant clobber
+ ant sane ; ant all ; ant buildjars   # for lib-debug
+ ant clobber
+ ant insane
+ ant -Dsane=false snapshot
+ cd tools/release
+ ant release
+    }}}
+ 
+ The release artifacts should now be available as {{{.zip}}} and {{{.tar.gz}}} files in the {{{tools/release/}}} directory.
+ 
+ To clean up, run {{{svn stat}}} to see which files don't naturally belong in the repository.
+