2002-10-20 22:40:18 +00:00
|
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
|
|
|
<html>
|
|
|
|
|
|
|
|
|
|
<!-- @author David Chandler -->
|
|
|
|
|
<!-- @date October 20, 2002 -->
|
|
|
|
|
<!-- @editor Emacs, baby! -->
|
|
|
|
|
|
|
|
|
|
<head>
|
|
|
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
|
|
|
<title>THDL Tools Build Systems</title>
|
|
|
|
|
</head>
|
|
|
|
|
|
|
|
|
|
<body>
|
|
|
|
|
<h1>THDL Tools Build Systems</h1>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
David Chandler has put together a build system for Jskad, Savant,
|
|
|
|
|
QuillDriver, the translation tool, and for the fonts. This document
|
|
|
|
|
describes them, and should be updated when we put together build
|
|
|
|
|
systems for the two diacritics packages and for Wylie Word.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
What is a <i>build system</i>, you ask? A build system is a set of
|
|
|
|
|
clear, repeatable procedures that software developers go by to
|
|
|
|
|
compile, run, test, create documentation, and cut releases. Our
|
|
|
|
|
build systems are fully automated, which provides a good basis for
|
|
|
|
|
collaborative development.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3>Table of Contents</h3>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="#glossary">Glossary</a>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="#whyant">Why we chose Apache Ant</a>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="#installant">Installing Apache Ant</a>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="#cvs">Setting things up to use CVS</a>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="#buildingfonts">Building the <code>Fonts</code>
|
|
|
|
|
module</a>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="#wwwmodule">Building the <code>www</code>
|
|
|
|
|
module</a> -- how to publish on this very web site, that is
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="#diacriticsmodule">Building the <code>Diacritics</code>
|
|
|
|
|
module</a>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="#wyliewordmodule">Building the <code>WylieWord</code>
|
|
|
|
|
module</a>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="#jskadmodule">Building the <code>Jskad</code>
|
|
|
|
|
module</a>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="#jskadsetup">Setting things up for your first build
|
|
|
|
|
of the <code>Jskad</code> module</a>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="#daytoday">Day-to-day development activities
|
|
|
|
|
with the <code>Jskad</code> module</a>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="#testingjskad">Testing</a>
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="#webstart">Why we chose Java Web Start and how it
|
|
|
|
|
works</a>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="#relwebstart">Cutting a Java Web Start release</a>
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h3>Glossary<a name="glossary"></a></h3>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
This document uses the following terms:
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
CVS -- "concurrent versions system", a piece of software used by
|
|
|
|
|
SourceForge and many others for source code revision control.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
WinCVS -- a front end for use on Windows that you can use rather
|
|
|
|
|
than the command-line cvs tools.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
<a name="sandbox">sandbox</a> -- a directory on your local machine
|
|
|
|
|
that mirrors one in our project's CVS repository. You get one by
|
|
|
|
|
using the command <code>'cvs checkout'</code>. It's called a
|
|
|
|
|
sandbox because you can safely play in it; your work will not
|
|
|
|
|
affect others until you commit your changes to the repository.
|
|
|
|
|
(Though if you really wanted to, you could create a CVS branch and
|
|
|
|
|
then even your commits (to that branch) wouldn't affect the work
|
|
|
|
|
of others on the trunk, or main branch.)
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
ssh, scp, sftp -- the software that SourceForge uses to allow you
|
|
|
|
|
to log in to their server without worrying about the security of
|
|
|
|
|
your password of the subsequent communications. ssh logs you in,
|
|
|
|
|
scp and sftp allow you to copy files to and from
|
|
|
|
|
<code>thdltools.sourceforge.net</code>. Windows users should
|
|
|
|
|
either get these tools with Cygwin or should install PuTTY; the
|
|
|
|
|
latter is probably easier.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
Ant -- a.k.a. Apache Ant. Software we use to compile and package
|
|
|
|
|
Java programs for distrution.
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h3>Why we chose Apache Ant<a name="whyant"></a></h3>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Ant is built from the ground up as a full-featured, extensible
|
|
|
|
|
build system for Java programs. If you use Ant, your
|
|
|
|
|
classpath-related headaches disappear (after clearing initial
|
|
|
|
|
hurdles), and you can be sure that the build will work the same on
|
|
|
|
|
Linux and the Mac as it does on Windows XP, because Ant itself is
|
|
|
|
|
a Java program.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Although Ant is for Java programs, it has enough features to make
|
|
|
|
|
it a viable choice of build system for non-Java stuff like our
|
|
|
|
|
Tibetan Machine Web fonts.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3>Installing Apache Ant<a name="installant"></a></h3>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
To install Apache's Jakarta Ant (or "Apache Ant" or simply "Ant"),
|
|
|
|
|
see the <a href="http://jakarta.apache.org/ant/"> Apache Ant</a>
|
|
|
|
|
website. Their instructions for installation are pretty good, but
|
|
|
|
|
you may have trouble if you're on Windows and you don't know how to
|
|
|
|
|
set environment variables (try Control
|
|
|
|
|
Panel->System->Advanced->Environment Variables) and the like.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
To test your installation, use cvs to checkout the
|
|
|
|
|
<code>Fonts</code> module. It has a simpler Ant build file
|
|
|
|
|
(<code>Fonts/build.xml</code>) than the <code>Jskad</code> module
|
|
|
|
|
has, so it's better for testing. Change directory to
|
|
|
|
|
<code>Fonts</code> and run the following command:
|
|
|
|
|
</p>
|
|
|
|
|
<blockquote>
|
|
|
|
|
<code>ant clean dist</code>
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
If you have any trouble, see Ant's FAQs and then e-mail David
|
|
|
|
|
Chandler.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
2002-10-25 11:06:04 +00:00
|
|
|
Now that you have a good installation of Ant itself, you may want
|
2002-10-20 22:40:18 +00:00
|
|
|
to install the <a href="http://www.vamphq.com/ant.html"> Vamp Ant
|
|
|
|
|
task</a> provided by the <a href="http://www.vamphq.com/"> Venus
|
|
|
|
|
Application Publisher</a>. You need this to cut <a
|
|
|
|
|
href="http://java.sun.com/products/javawebstart/"> Java Web
|
|
|
|
|
Start</a> releases of Jskad, Savant, QuillDriver, and the
|
2002-10-25 11:06:04 +00:00
|
|
|
translation tool. You <b>do not</b> need it otherwise.
|
2002-10-20 22:40:18 +00:00
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Installing Vamp's Ant task is simple enough, and is in fact simpler
|
|
|
|
|
than Vamp's web pages of October 1, 2002 imply. That is, if you
|
|
|
|
|
have installed Ant 1.5.1 or later, then you can simply drop
|
|
|
|
|
<code>vamp.jar</code> into Ant's <code>lib</code> directory and
|
|
|
|
|
forget about changing your classpath.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h3>Setting things up to use CVS <a
|
|
|
|
|
name="cvs"></a></h3>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
If you're working on Windows, it's probably easiest to follow <a
|
|
|
|
|
href="http://sourceforge.net/docman/display_doc.php?docid=766&group_id=1">
|
|
|
|
|
SourceForge's instructions</a> on using WinCVS and PuTTY. The
|
|
|
|
|
instructions there aren't up to date for the latest version of
|
|
|
|
|
WinCVS (1.3b8 as of this writing). Instead of telling WinCVS about
|
|
|
|
|
<code>plink.exe</code> in the non-existent <code>Ports</code> tab of
|
|
|
|
|
the <code>Admin->Preferences</code> menu, you must click the
|
|
|
|
|
Settings button next to the server type (<code>"ssh"</code>) and
|
|
|
|
|
click the <code>'If ssh is not in the path'</code> checkbox, and
|
|
|
|
|
enter <code>plink.exe</code>'s full path there.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Also note that <a href="http://www.computas.com/pub/wincvs-howto/">
|
|
|
|
|
this page</a> is very helpful; it's about how to run WinCVS.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
If you're using WinCVS 1.3b8, note that it has a bug -- it truncates
|
|
|
|
|
the output of <code>'cvs diff'</code> (as explained in <a
|
|
|
|
|
href="http://sourceforge.net/tracker/index.php?func=detail&aid=622680&group_id=10072&atid=110072">
|
|
|
|
|
this bug report</a>). For that reason, you may wish to use what
|
|
|
|
|
WinCVS calls an "external diff" program, which is easy to install
|
|
|
|
|
and configure. Try using <a
|
|
|
|
|
href="http://www.prestosoft.com/examdiff/examdiff.htm">
|
|
|
|
|
ExamDiff</a>.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
If you're on Linux or Unix, SF.net's site docs are excellent. If
|
|
|
|
|
you're on a Mac, and SF.net's docs don't do the trick, you're in
|
|
|
|
|
trouble.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h3>Building the <code>Fonts</code> module<a
|
|
|
|
|
name="buildingfonts"></a></h3>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
The <code>Fonts</code> CVS module comes with an Apache Ant build
|
|
|
|
|
system. We made this choice because the <code>Jskad</code> CVS
|
|
|
|
|
module already has an Apache Ant build system, and because Ant is
|
|
|
|
|
more than powerful enough for our needs. For this module, our only
|
|
|
|
|
task is to cut releases. There is nothing to compile here; the only
|
|
|
|
|
task that a developer will face is updating the associated
|
|
|
|
|
documentation and then cutting a new release, ready to go up on
|
|
|
|
|
SourceForge's File Release System (FRS).
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
To cut releases for one or both of the Tibetan Machine Web and
|
|
|
|
|
Tibetan Machine, do the following:
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
<li>
|
|
|
|
|
use cvs to checkout the <code>Fonts</code> module. If you have
|
|
|
|
|
already checked it out, run <code>'cvs -f update -d'</code> (in
|
|
|
|
|
WinCVS, hold down the shift key while selecting "Update" and
|
|
|
|
|
then be sure the "Create missing directories that exist in the
|
|
|
|
|
repository" box is checked).
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
make whatever changes you need to
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
be certain the the release notes (a text or html file, I
|
|
|
|
|
believe) are under CVS control. Perhaps you'll reuse an
|
|
|
|
|
existing document, or perhaps you'll have to add a file to the
|
|
|
|
|
repository. Go to <a
|
|
|
|
|
href="http://sourceforge.net/project/showfiles.php?group_id=61934">
|
|
|
|
|
our project's download page</a> and see how we've done release
|
|
|
|
|
notes in the past.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
commit those changes to the repository
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="#installant">install Apache Ant</a>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
change directory to <code>Fonts</code> and run the following
|
|
|
|
|
command:
|
|
|
|
|
<blockquote>
|
|
|
|
|
<code>ant</code>
|
|
|
|
|
</blockquote>
|
|
|
|
|
If you have any problems, be sure you're using the correct
|
|
|
|
|
version of Ant and then read Ant's FAQs and documentation. Or
|
|
|
|
|
you can e-mail David Chandler. If it turns out that the problem
|
|
|
|
|
is in the Ant build file <code>Fonts/build.xml</code>, make the
|
|
|
|
|
required changes and be sure to commit them to the repository.
|
|
|
|
|
Now run the following command to rebuild the releases:
|
|
|
|
|
<blockquote>
|
|
|
|
|
<code>ant clean dist</code>
|
|
|
|
|
</blockquote>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
after being sure that your Fonts directory is a mirror of the
|
|
|
|
|
one in the repository, use cvs to tag this revision that you
|
|
|
|
|
wish to release with a name that another developer, years down
|
|
|
|
|
the road, will recognize as referring to this release. To do
|
|
|
|
|
this, you can run <code>'cvs -f rtag <i>tag-name</i>
|
|
|
|
|
Fonts'</code> or (and this is preferred) you can run <code>'cvs
|
|
|
|
|
-f tag -c <i>tag-name</i>'</code>. Good tag names are like the
|
|
|
|
|
following:
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<code>Fonts_1_0</code> (referring to the 1.0 release of the
|
|
|
|
|
Fonts module)
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>September_23_2002_release</code> (referring to the
|
|
|
|
|
release of the Fonts module made on September 23, 2002
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
Note that tagging for a release of just the Tibetan Machine Web
|
|
|
|
|
fonts and not the Tibetan Machine fonts is <i>no different</i>
|
|
|
|
|
than tagging for a simulaneous release of both.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Now that you've tagged this release, it will be possible for any
|
|
|
|
|
other developer to recreate the same release. This is the heart
|
|
|
|
|
of a good build system -- clear, repeatable procedures that
|
|
|
|
|
aren't painful to follow.
|
|
|
|
|
</li>
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h3>Building the <code>www</code> module<a name="wwwmodule"></a></h3>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
<a href="http://thdltools.sourceforge.net/"> Our SourceForge.net
|
|
|
|
|
website</a> is entirely under CVS control. This means that we can
|
|
|
|
|
freely make changes, knowing that they are never lost. It also
|
|
|
|
|
means that downloading our <a
|
|
|
|
|
href="http://cvs.sourceforge.net/cvstarballs/thdltools-cvsroot.tar.gz">
|
|
|
|
|
nightly CVS repository tarball</a> is all that is necessary to save
|
|
|
|
|
a backup copy of our SF.net web site.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
To change an existing web page or to add a new one, you must do the
|
|
|
|
|
following:
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
First use cvs to checkout the <code>www</code> module. If you've
|
|
|
|
|
already done that, then please use cvs to update (using <code>'cvs
|
|
|
|
|
update -d'</code> if you want to create missing directories that
|
|
|
|
|
exist in the repository) now.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
To add a file or directory, use <code>'cvs add'</code>. Change
|
|
|
|
|
any files you wish. Now validate your HTML using W3C's <a
|
|
|
|
|
href="http://validator.w3.org/"> validator</a>. Once it passes
|
|
|
|
|
with no errors, commit your changes.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
Now you must update the CVS <a href="#sandbox"> sandbox</a> at
|
|
|
|
|
<code>thdltools.sourceforge.net:/home/groups/t/th/thdltools/htdocs</code>.
|
|
|
|
|
To do so, use PuTTY or another <code>ssh</code> to log in to
|
|
|
|
|
<code>thdltools.sourceforge.net</code>. Now change directory
|
|
|
|
|
(<code>cd</code>) to
|
|
|
|
|
<code>/home/groups/t/th/thdltools/htdocs</code> and run <code>'cvs
|
|
|
|
|
-f update -d -P'</code>. You'll see your changes being made to
|
|
|
|
|
the "real" website. Surf to <a
|
|
|
|
|
href="http://thdltools.sourceforge.net/"> the website</a> and see
|
|
|
|
|
for yourself.
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<h4>Updating the parts of the website not in the <code>www</code>
|
|
|
|
|
module<a name="updateapidocs"></a></h4>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Not all of the material up at our SF.net <a
|
|
|
|
|
href="http://thdltools.sourceforge.net/"> website</a> is in the
|
|
|
|
|
<code>www</code> CVS module, but most of it is. Currently, the only
|
|
|
|
|
exception is the <a href="http://thdltools.sourceforge.net/api/">
|
|
|
|
|
Javadoc API documentation</a> for Jskad, Savant, QuillDriver, and
|
|
|
|
|
the translation tool.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Here is how to update these API docs:
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<code>http://thdltools.sourceforge.net/api</code> lives at
|
|
|
|
|
<code>/home/groups/t/th/thdltools/htdocs/api</code>. To update
|
|
|
|
|
it, first commit any changes you've made to the repository.
|
|
|
|
|
(This, combined with the date stamp that Ant puts into our
|
|
|
|
|
Javadoc docs, will give other developers enough information to
|
|
|
|
|
recover the revision of the source files that you used. But
|
|
|
|
|
feel free to <code>'cvs tag'</code> the revision explicitly if
|
|
|
|
|
you think it's important.)
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
Now simply run <code>'ant private-javadocs-dist'</code> from the
|
|
|
|
|
<code>Jskad</code> directory, which creates
|
|
|
|
|
<code>Jskad/dist/docs/private-javadocs-DSTAMP.zip</code>.
|
|
|
|
|
Examine the output for warnings; resolve them if necessary.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
Now <code>scp</code> that file over with the command
|
|
|
|
|
<blockquote>
|
|
|
|
|
<code>scp dist/docs/private-javadocs-WHATEVER.zip
|
|
|
|
|
yourUserId@thdltools.sourceforge.net/home/groups/t/th/thdltools/</code>
|
|
|
|
|
</blockquote>
|
|
|
|
|
or use PuTTY's <code>scp</code> to do something equivalent.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
Now, shell in to <code>thdltools.sourceforge.net</code> with
|
|
|
|
|
<code>'ssh -l yourUserId thdltools.sourceforge.net'</code> or
|
|
|
|
|
with PuTTY.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
Change directory (<code>cd</code>) to
|
|
|
|
|
<code>/home/groups/t/th/thdltools/htdocs/</code>.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
While you're here, do a <code>'cvs -f update -d -P'</code> --
|
|
|
|
|
just in case some developer made changes to the web pages but
|
|
|
|
|
forgot to update (don't worry about setting the CVSROOT--cvs is
|
|
|
|
|
smart enough to determine everything (but your password)
|
|
|
|
|
automatically).
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
Anyway, now run <code>'rm -fr api'</code> (from the
|
|
|
|
|
<code>htdocs/</code> directory).
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
Now run <code>'mkdir api'</code>.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
Now run <code>'cd api'</code>.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
Now run <code>'unzip
|
|
|
|
|
../../private-javadocs-WHATEVER.zip'</code>.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
See if <code>http://thdltools.sourceforge.net/api/</code> looks
|
|
|
|
|
up to date (see the date at the very bottom of the page, for
|
|
|
|
|
starters). Also, verify that links to J2SE Javadoc
|
|
|
|
|
documentation are functioning -- click on a link to
|
|
|
|
|
<code>java.lang.Object</code> and be sure that it works. If
|
|
|
|
|
everything is fine, delete
|
|
|
|
|
<code>../../private-javadocs-WHATEVER.zip</code> and log out.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
<b>UPDATE THESE INSTRUCTIONS</b> if something above is wrong or
|
|
|
|
|
unclear.
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
That's all!
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h3>Building the <code>Diacritics</code> module<a
|
|
|
|
|
name="diacriticsmodule"></a></h3>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
We don't yet have source code in this module. Check back here once
|
|
|
|
|
we do.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h3>Building the <code>WylieWord</code> module<a
|
|
|
|
|
name="wyliewordmodule"></a></h3>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
We don't yet have source code in this module. Check back here once
|
|
|
|
|
we do.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h3>Building the <code>Jskad</code> module<a name="jskadmodule"></a></h3>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
The following sections describe how to use the Ant build system we
|
|
|
|
|
have for the <code>Jskad</code> module.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
The first thing to note is that the <code>Jskad</code> module is
|
|
|
|
|
misnamed. We have all our Java code inside this module, including
|
|
|
|
|
Jskad, Savant, QuillDriver, and the translation tool.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h4>Setting things up for your first build of the <code>Jskad</code>
|
|
|
|
|
module<a name="jskadsetup"></a></h4>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
You'll have to first get your computer set up to use CVS. See <a
|
|
|
|
|
href="#cvs">above</a>.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
The next thing you'll need to do is get a CVS <a
|
|
|
|
|
href="#sandbox">sandbox</a> -- a <code>Jskad</code> directory on
|
|
|
|
|
your local computer. Use <code>'cvs checkout Jskad'</code> or
|
|
|
|
|
WinCVS's "Checkout module" command to do so.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Now go get the JARs you need. Be sure to note which versions you
|
|
|
|
|
get, because you'll need to mention that in the release notes of any
|
|
|
|
|
releases you cut. The following are needed:
|
|
|
|
|
</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
We use <a href="http://xml.apache.org/xalan-j/"> Xalan</a> for
|
|
|
|
|
XSLT, and its binary distribution contains JARs for Xalan
|
|
|
|
|
<i>and</i> <a href="http://xml.apache.org/xerces2-j/index.html">
|
|
|
|
|
Xerces</a> -- handy. You only need to download Xerces' JARs
|
|
|
|
|
separately if you need a bug fix from a later release than that
|
|
|
|
|
included in Xalan's. After downloading, move
|
|
|
|
|
<code>xalan.jar</code>, <code>xercesImpl.jar</code>, and
|
|
|
|
|
<code>xml-apis.jar</code> to <code>Jskad/extensions/</code>.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
We also use <code>jdom.jar</code> from <a href="http://jdom.org/">
|
|
|
|
|
JDOM.org</a>.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
We also use (conditional on the <code>thdl.media.player</code>
|
|
|
|
|
option) the <a
|
|
|
|
|
href="http://java.sun.com/products/java-media/jmf/"> Java(TM)
|
|
|
|
|
Media Framework</a>. After it is installed, either change your
|
|
|
|
|
CLASSPATH to include its <code>jmf.jar</code>, or avoid the
|
|
|
|
|
classpath hassle by copying <code>jmf.jar</code> to
|
|
|
|
|
<code>Jskad/extensions/</code>.
|
|
|
|
|
</li>
|
|
|
|
|
|
|
|
|
|
<li>
|
|
|
|
|
We also use (conditional on the <code>thdl.media.player</code>
|
|
|
|
|
option) <a href="http://www.apple.com/quicktime/"> QuickTime for
|
|
|
|
|
Java</a>. Installing it requires installing QuickTime, selecting
|
|
|
|
|
a "Custom" install, and checking the box for QuickTime for Java.
|
|
|
|
|
After it is installed, either change your CLASSPATH to include its
|
|
|
|
|
<code>QTJava.zip</code>, or avoid the classpath hassle by copying
|
|
|
|
|
<code>QTJava.zip</code> to <code>Jskad/extensions/drop-ins</code>.
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
If you need to add something else to the classpath, be it a .jar
|
|
|
|
|
file, a .zip file, or a directory, you have several options. You
|
|
|
|
|
can set your CLASSPATH environment variable, or you can call Ant
|
|
|
|
|
using <code>'ant -Dadditional.class.path=c:\my.jar'</code>, or you
|
|
|
|
|
can drop JAR or ZIP files into
|
|
|
|
|
<code>Jskad/extensions/drop-ins</code>.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
While you're hacking, use our <a href="api/"> API docs on the
|
|
|
|
|
web</a>, or <a href="#makeapidocs"> build your own</a>.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h4>Day-to-day development activities with the <code>Jskad</code>
|
|
|
|
|
module<a name="daytoday"></a></h4>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
This section describes how our build system interacts with your
|
|
|
|
|
daily work hacking on Jskad, Savant, QuillDriver, and the
|
|
|
|
|
translation tool.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h5>Compiling</h5>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Compiling any of the tools is a simple matter. First, ensure that
|
|
|
|
|
you are in the <code>Jskad/</code> directory of your <a
|
|
|
|
|
href="#sandbox">sandbox</a>.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Now run <code>'ant <i>program</i>-compile'</code> to create a
|
|
|
|
|
directory tree <code>Jskad/bin/<i>program</i>/</code> that contains
|
|
|
|
|
all the .class files and needed resources (.ini files, .xsl files,
|
|
|
|
|
et cetera).
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Or you may run <code>'ant <i>program</i>-dist'</code> to create a
|
|
|
|
|
JAR file <code>Jskad/dist/lib/<i>program</i>-vanilla.jar</code> that
|
|
|
|
|
contains all the .class files and needed resources, but does not
|
|
|
|
|
contain any third-party JARs.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
You may also run <code>'ant <i>program</i>-jws'</code> to create a
|
|
|
|
|
Java Web Start release. See <a href="#relwebstart">below</a> to
|
|
|
|
|
learn more about this.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
<b>Gotcha:</b> We currently have the build system set up so that it
|
|
|
|
|
builds a program, say Jskad, given merely the name of the main
|
|
|
|
|
class, say <code>org.thdl.tib.input.Jskad</code>. This means that
|
|
|
|
|
our releases include only classes that we're actually using. But it
|
|
|
|
|
also means that your changes to any but the main class will not
|
|
|
|
|
cause recompilation. You must use <code>'ant clean'</code> before
|
|
|
|
|
recompiling. In addition, you should clean after any cvs update.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
The alternative to specifying just the main class is specifying
|
|
|
|
|
every needed class. If you do this, Ant often rebuilds the correct
|
|
|
|
|
classes. But you may have to modify <code>build.xml</code> when you
|
|
|
|
|
add a new file, and your releases may include vestigial classes.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h5>Running</h5>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Running the tools is easy for a developer. Just run <code>'ant
|
|
|
|
|
<i>program</i>-run'</code>, where <i>program</i> is one of
|
|
|
|
|
<code>jskad</code>, <code>tt</code>, <code>savant</code>, or
|
|
|
|
|
<code>qd</code>. This deals with classpaths and all of that, and it
|
|
|
|
|
compiles beforehand if needed. Note the gotcha above if you're
|
|
|
|
|
rerunning after changing the source code -- you'll have to use
|
|
|
|
|
<code>'ant clean <i>program</i>-run'</code>. If you modify a
|
|
|
|
|
resource, such as <code>Jskad/source/options.txt</code>, there are
|
|
|
|
|
no gotchas -- Ant is smart enough to handle this.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h5>Generating API Documentation<a name="makeapidocs"></a></h5>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
While you're hacking, use our <a href="api/"> API docs on the
|
|
|
|
|
web</a>, or build your own Javadoc API docs using <code>'ant
|
|
|
|
|
public-javadocs'</code> (to see only protected and public members)
|
|
|
|
|
or <code>'ant private-javadocs'</code> (to see all members).
|
|
|
|
|
They'll be waiting for you in
|
|
|
|
|
<code>Jskad/docs/{public,private}-javadocs/</code>. If you want to
|
|
|
|
|
update the API docs on our website, follow <a
|
|
|
|
|
href="#updateapidocs">these instructions</a>.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h5>Integration with IDEs such as Eclipse</h5>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Nowadays, any good Java IDE is aware of Ant and will let you use Ant
|
|
|
|
|
for the things it is good at while using the IDE for the things it
|
|
|
|
|
is good at. Ask David Chandler how he got Eclipse up and running;
|
|
|
|
|
he did it without too much trouble.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h5>Testing<a name="testingjskad"></a></h5>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
We will soon use <a href="http://junit.org/"> JUnit</a> to provide
|
|
|
|
|
automated unit tests. Running them will be as simple as making Ant
|
|
|
|
|
aware of JUnit and then running <code>'ant check'</code>. <!-- DLC
|
|
|
|
|
FIXME -->
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
To make testing easy, you should use interfaces rather than
|
|
|
|
|
hard-wiring in calls to classes that are difficult to instantiate.
|
|
|
|
|
For example, if we were to make use of a database class in our
|
|
|
|
|
DuffPane class, doing so directly would mean that the database
|
|
|
|
|
software would have to be properly installed and up and running in
|
|
|
|
|
order to test DuffPane individually. If you create an interface and
|
|
|
|
|
use the database only through that interface, then creating a <a
|
|
|
|
|
href="http://mockobjects.com"> mock object</a> that pretends to
|
|
|
|
|
be that database but returns canned answers is a simple matter.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h5>Modifying <code>Jskad/build.xml</code></h5>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Should you need to modify the Ant build file
|
|
|
|
|
<code>Jskad/build.xml</code>, feel free to ask David Chandler to do
|
|
|
|
|
it for you. Or just look at the contents of that file and find
|
|
|
|
|
something similar to what you're doing. There are a few comments in
|
|
|
|
|
the file, and all commonly used functionality is factored out into
|
|
|
|
|
targets that are then summoned via <code>antcall</code> tasks.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h4>Why we chose Java Web Start and how it works<a name="webstart"></a></h4>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
<a href="http://java.sun.com/products/javawebstart/"> Java Web
|
|
|
|
|
Start</a> makes it possible (in theory, anyway) to install a complex
|
|
|
|
|
application like Savant with one mouse click of a link in your
|
|
|
|
|
favorite web browser and one more click of a "Yes, install Savant"
|
|
|
|
|
button in a dialog box (necessary because our applications require
|
|
|
|
|
security privileges to read and write from disk etc.). Upon the
|
|
|
|
|
second run of the program, Java Web Start asks the user if they want
|
|
|
|
|
to create shortcuts on their computer. Also, any time the program
|
|
|
|
|
is invoked (from a shortcut or a web link) and a network connection
|
|
|
|
|
is found, new versions of the software will be downloaded
|
|
|
|
|
automatically, keeping the user up to date.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
In addition, the <a href="http://www.vamphq.com/"> Venus Application
|
|
|
|
|
Publisher</a> provides a mechanism for creating CD-ROM-based
|
|
|
|
|
installers that load our Java Web Start code into the user's Web
|
|
|
|
|
Start cache directory. Then running the software will check for
|
|
|
|
|
updates as described above. (I don't know if we'll ever use this,
|
|
|
|
|
and it's kind of ugly, but it's here.)
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
For the above scenario to play out, the user must have installed a
|
|
|
|
|
recent (1.2 or later) Java runtime environment. That's it from the
|
|
|
|
|
user's point of view.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<a name="webstartserver"></a>
|
|
|
|
|
<p>
|
|
|
|
|
The web server that delivers the content must associate the MIME
|
|
|
|
|
type application/x-java-jnlp-file with the "jnlp" extension and must
|
|
|
|
|
associate the MIME type application/x-java-archive-diff with the
|
|
|
|
|
"jardiff" extension. In addition, if you want to be able to serve
|
|
|
|
|
up a new release with the least difficulty (simply dropping a .war
|
|
|
|
|
file (a Java Web ARchive) into the appropriate directory on the
|
|
|
|
|
server), the server must run a J2EE application server such as
|
|
|
|
|
Apache's Tomcat.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h4>Cutting a Java Web Start release<a name="relwebstart"></a></h4>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
For the reasons stated above, Java Web Start (JWS) is our
|
|
|
|
|
distribution mechanism of choice. But cutting a Java Web Start
|
|
|
|
|
release is not the easiest thing you've ever done. For one thing,
|
|
|
|
|
because our applications require access to the local disk, they must
|
|
|
|
|
ask for security privileges. JWS warns users not to grant such
|
|
|
|
|
privileges unless they know the software provider is trustworthy.
|
|
|
|
|
Trust depends in turn on identity, and identity is proven by public
|
|
|
|
|
key cryptography. So to cut a JWS release, you have to sign your
|
|
|
|
|
JARs and rejar and sign any third-party JARs. (If signing JARs is
|
|
|
|
|
new to you, the J2SE documentation on the subject is okay, but
|
|
|
|
|
hopefully reading below will tell you all you need to know.)
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
First, be sure you've installed Vamp's Ant task as described <a
|
|
|
|
|
href="#installant"> above</a>.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Second, create the release notes and the changelog. These should be
|
|
|
|
|
two different text files. Somewhere in one or both, you should
|
|
|
|
|
mention the versions of the third-party JARs and APIs that we have
|
|
|
|
|
packaged with our release. <b>Most importantly, put in a link to
|
|
|
|
|
the web server on which you're going to put the web start
|
|
|
|
|
release!</b> Commit these text files to the repository (adding them
|
|
|
|
|
first if necessary).
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Third, commit any changes you've made to the repository. After
|
|
|
|
|
being sure that your <code>Jskad</code> directory is a mirror of the
|
|
|
|
|
one in the repository, use cvs to tag this revision that you wish to
|
|
|
|
|
release with a name that another developer, years down the road,
|
|
|
|
|
will recognize as referring to this release. To do this, you can
|
|
|
|
|
run <code>'cvs -f rtag <i>tag-name</i> Jskad'</code> or (and this is
|
|
|
|
|
preferred) you can run <code>'cvs -f tag -c <i>tag-name</i>'</code>.
|
|
|
|
|
Good tag names are like the following:
|
|
|
|
|
</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<code>thdl_tools_1_0</code> (referring to the 1.0 release of the
|
|
|
|
|
Jskad module)
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<code>September_23_2002_release</code> (referring to the
|
|
|
|
|
release of all programs in Fonts module made on September 23, 2002
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
As you may have inferred, we release all four programs when we
|
|
|
|
|
release any one of them. This is only a half-truth, though--we
|
|
|
|
|
release the unified source distribution any time we release a binary
|
|
|
|
|
distribution, but we don't necessarily put out all four binary
|
|
|
|
|
distributions in unison.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
2002-10-25 11:56:38 +00:00
|
|
|
Now run
|
|
|
|
|
</p>
|
|
|
|
|
<blockquote><code>ant -Dkeystore="file:///c:/thdl/sandboxes/Jskad/your.keystore"<br>
|
|
|
|
|
-Dkeystore.password=baz<br>
|
|
|
|
|
-Ddgkey.password=foo<br>
|
|
|
|
|
-Dkey.alias="Johnny Developer"<br>
|
|
|
|
|
-Djnlp.codebase="http://your.web.server/THDL_STUFF"<br>
|
|
|
|
|
<i>program</i>-jws'</code>
|
|
|
|
|
</blockquote>
|
|
|
|
|
<p>
|
2002-10-20 22:40:18 +00:00
|
|
|
where <i>program</i> is one of <code>jskad</code>, <code>tt</code>,
|
|
|
|
|
<code>savant</code>, or <code>qd</code>. This cleans first, so your
|
|
|
|
|
changes will be respected. This then creates a WAR file
|
|
|
|
|
<code>Jskad/dist/java-web-start/<i>program</i>-JWS.war</code>. This
|
|
|
|
|
also extracts the signed JAR from inside that WAR, which is handy if
|
|
|
|
|
you're deploying to a web server that isn't running a J2EE
|
|
|
|
|
application server. More on that below.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
The argument to <code>-Dkeystore</code> is a URL like
|
|
|
|
|
<code>file:///c:/foo/keystore</code>. This should be a keystore
|
|
|
|
|
that you've created with keytool. We haven't yet paid the money to
|
|
|
|
|
get a real X.509 key, so create your own. Users will see a nasty
|
|
|
|
|
warning saying that we may not be who we say we are, but so be it.
|
|
|
|
|
Each key in your key store has an associated alias, such as your
|
|
|
|
|
name. Specify it as the argument to <code>-Dkey.alias</code>. The
|
|
|
|
|
other two arguments are the password for the keystore as a whole
|
|
|
|
|
(<code>-Dkeystore.password</code>) and the password for the specific
|
|
|
|
|
key whose alias you're giving.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Inspect the output for warnings. Ignore the warning about
|
|
|
|
|
<code>"[vampwar]
|
|
|
|
|
org.apache.velocity.runtime.exception.ReferenceException: reference
|
|
|
|
|
: template = html/test.html [line 37,column 14] : $jnlp-url is not a
|
|
|
|
|
valid reference."</code> but fix any others.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
If you wish to deploy to a J2EE application server, such as Apache's
|
|
|
|
|
Tomcat, now copy the <code>.war</code> file to the server. You're
|
|
|
|
|
done with the binary part of the release.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
If you're deploying to a plain-vanilla web server, first ensure that
|
|
|
|
|
its MIME type associations are correct (see <a
|
|
|
|
|
href="#webstartserver">above</a>). Now ignore the <code>.war</code>
|
2002-10-25 11:56:38 +00:00
|
|
|
file and copy the appropriate <code>.jnlp</code> file(s) and the
|
|
|
|
|
appropriate JAR(s) from <code>Jskad/dist/java-web-start/</code> to
|
|
|
|
|
the webserver. Those two files are all you need, and you don't need
|
|
|
|
|
to edit the <code>.jnlp</code> file because you specified the
|
|
|
|
|
<code>jnlp.codebase</code> property.
|
2002-10-20 22:40:18 +00:00
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Now put up a source release on SourceForge's File Release System
|
|
|
|
|
(FRS). After ensuring that you've made NOT EVEN ONE CHANGE to your
|
|
|
|
|
sandbox, and after updating it, and after verifying that this
|
|
|
|
|
revision is cvs-tagged appropriately, use <code>'ant
|
|
|
|
|
src-dist'</code> to create
|
|
|
|
|
<code>Jskad/source/THDL-Tools-src-<i>todays-date</i>.zip</code>.
|
|
|
|
|
Now put this zip file up on the FRS with the appropriate release
|
|
|
|
|
notes and changelog (which should have been committed and tagged in
|
|
|
|
|
the repository).
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
You're done! <b>Except, of course, for the gotcha:</b> At present,
|
|
|
|
|
only the translation tool and Jskad have working Java Web Start
|
|
|
|
|
releases; Savant's and QuillDriver's are on the way. Savant and
|
|
|
|
|
QuillDriver, like Jskad, requires all-permissions security. That
|
|
|
|
|
means that <code>xalan.jar</code>, <code>xercesImpl.jar</code>, and
|
|
|
|
|
<code>xml-apis.jar</code> need to be jar-signed by the same
|
|
|
|
|
certificate as Savant. We don't yet do this automatically <!-- DLC
|
|
|
|
|
FIXME -->, but here's how to do this manually:
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<ol>
|
|
|
|
|
<li>unjar these jars.</li>
|
|
|
|
|
<li>delete their META-INF directory, which i think contains signature info.</li>
|
|
|
|
|
<li>rejar, then sign with appropriate certificate.</li>
|
|
|
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Now send an e-mail to <a
|
|
|
|
|
href="thdltools-announce@lists.sourceforge.net">
|
|
|
|
|
thdltools-announce@lists.sourceforge.net</a> telling users where the
|
|
|
|
|
JWS binary release is, where the source code distribution is, and
|
|
|
|
|
why they should upgrade or try it out.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<!-- THDLTools FOOTER: -->
|
|
|
|
|
<hr>
|
|
|
|
|
|
|
|
|
|
<i>
|
|
|
|
|
Please
|
|
|
|
|
|
|
|
|
|
<a href="mailto:thdltools-devel@lists.sourceforge.net">
|
|
|
|
|
e-mail us</a>
|
|
|
|
|
|
|
|
|
|
your comments about this page.
|
|
|
|
|
</i>
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
|
|
|
|
|
|
|
|
The
|
|
|
|
|
|
|
|
|
|
<a href="index.html">
|
|
|
|
|
THDL Tools</a>
|
|
|
|
|
|
|
|
|
|
project is generously hosted by:
|
|
|
|
|
|
|
|
|
|
<!--
|
|
|
|
|
|
|
|
|
|
DO NOT DELETE THE SF.NET LOGO.
|
|
|
|
|
|
|
|
|
|
We have a choice of colors and sizes for this logo (see
|
|
|
|
|
"https://sourceforge.net/docman/display_doc.php?docid=790&group_id=1"),
|
|
|
|
|
but we do not have the option of removing it. SourceForge requests
|
|
|
|
|
that we put it on each web page for our project, and to give us
|
|
|
|
|
incentive to do so, they will not track the number of hits for our
|
|
|
|
|
project web pages unless we put this link in. To track hits, see
|
|
|
|
|
"http://sourceforge.net/project/stats/index.php?report=months&group_id=61934".
|
|
|
|
|
|
|
|
|
|
-->
|
|
|
|
|
<a href="http://sourceforge.net/">
|
|
|
|
|
<img src="http://sourceforge.net/sflogo.php?group_id=61934&type=1"
|
|
|
|
|
width="88" height="31" border="0" alt="SourceForge Logo">
|
|
|
|
|
</a>
|
|
|
|
|
<!-- AGAIN, DO NOT DELETE THE SF.NET LOGO. -->
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
