Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Tue, 12 Oct 2010 17:35:58 -0000
Message-ID: <20101012173558.49319.77475@eosnew.apache.org>
Subject: 
 =?utf-8?q?=5BDb-derby_Wiki=5D_Update_of_=22SnapshotsAndQuickBuilds=22_by_?=
 =?utf-8?q?RichardHillegas?=

Dear Wiki user,

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

The "SnapshotsAndQuickBuilds" page has been changed by RichardHillegas.
http://wiki.apache.org/db-derby/SnapshotsAndQuickBuilds

--------------------------------------------------

New page:
This is an appendix to the overall Derby release instructions found here: D=
erbySnapshotOrRelease

'''Table of Contents'''
<<TableOfContents(4)>>

=3D Snapshots =3D

In essence a snapshot differs from a full release (feature, or bug fix rele=
ase) 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 distribu=
tion, and likely cut from a branch. =


 1. You don't have to polish the release notes for snapshots.

 1. For snapshots, the vetting cycle is shorter and the community is willin=
g to tolerate regressions and serious bugs in the interests of garnering ea=
rly feedback. =


 1. Snapshots don't necessarily include everything included in a full relea=
se, for example demos, plugins etc.

 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 inter=
ested testers can grab it.


=3D Making a (private) Quick Build of Release Artifacts =3D

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 i=
n certain subdirectories of a -bin distribution, reviewing generated releas=
e 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 t=
he 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 '''''suitab=
le 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 is suitable for reviewing the file=
 structure of a release, among other things, do the following steps (extrac=
ted from the full release procedure description above):

 1. Check out (or update) the source tree from which you want to build rele=
ase 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 descr=
ibed in [[http://svn.apache.org/repos/asf/db/derby/code/trunk/BUILDING.html=
|BUILDING.html]]

 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.or=
g/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 imp=
ortant thing here is to include a pointer to you doc build, for example:
   {{{
docs.out=3D/export/home/tmp/user/docTrunk/trunk/out
   }}}

 1. Include the following in your ''ant.properties'' file (for 10.3 or newe=
r), modified to suit your environment:
   {{{
j14lib=3D/usr/local/java/jdk1.4/jre/lib
# For 10.4 or newer:
j15lib=3D/usr/local/java/jdk1.5/jre/lib
# For JDBC 4 support
jdk16=3D/usr/local/java/jdk1.6.0
# If you want Java ME-support:
jsr169compile.classpath=3D/home/user/lib/cdc/jsr169.jar:/home/user/lib/cdc/=
btclasses.zip
#  May not be necessary (?):
relnotes.src.reports=3D/home/user/derby/relnotes-reports # empty directory
   }}}

 1. Ensure that 'sane=3Dtrue' and 'debug=3Dtrue' are not present in your ''=
ant.properties'', by removing or commenting out those lines if present.

 1. In the top-level directory of the source code tree, do:
   {{{
ant prepareforrelease
cd tools/release
ant release
   }}}

   ''prepareforrelease'' will actually do:
   {{{
# clean up classes, 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
ant clobber
ant sane ; ant all ; ant buildjars   # for lib-debug
ant clobber
ant insane
ant -Dsane=3Dfalse snapshot
}}}

   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.