Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Fetching contributors…

Cannot retrieve contributors at this time

392 lines (284 sloc) 14.538 kb
The release environment:
Start releases in the morning. If there are problems, you have time to recover.
On conan all release oriented directories and files point through the
symbolic link:
So we have(in an abbreviated way):
/content/software/idv/data --> current/data
/content/software/idv/docs --> current/docs
/content/software/idv/webstart/IDV --> current/webstart/IDV
Run the test suite (see below) and make sure to update and
check in /ucar/unidata/idv/resources/
Before making a release, make sure to update the release notes
in auxdata/docs/userguide/content/ReleaseNotes.html
- Try to add descriptive verbage to each item in the Release Notes.
- The questions (q attribute) should be camel cased (i.e. first letter of each word should be capitalized).
Words like for, and, a, the don't need to be capitalized.
- If there are other pages in the user guide with more information on the
change (like a new control page, or something in the preferences), add a link to it from the description.
- The format for menus and submenus is Menu->Submenu->Sub-submenu.
You can use the [ug::menu] macro which will format and bold the menus for you.
If there are multiple words in a menu, enclose them in braces {}.
Examples: [ug::menu Edit Preferences] will show up as Edit->Preferences.
[ug:menu Edit {Remove All Displays}] will show up as Edit->Remove All Displays
- Release Notes should include items since the last previous major release.
Updates (e.g. 3.0u1) should include all the notes from the first release of that series (e.g. 3.0)
up to the current one.
- It's good to update the Release Notes when you add something new so you don't forget about it
when the official release comes around.
When you are ready to make a release, run:
cd /share/idv/release
svn update build.xml
./buildIdv release
Note that this script has a dependency on install4j license server.
The user running this script must point to the right license server.
As of October 2011, the license server is running on abbott (not zero).
License server configuration information can be found in ~/.install4j4/config.xml.
Therein you will find the license server host. More information on the
install4j license server (including where to download the server) can
be found here:
To start the server on abbott the startup script is/etc/rc5.d/S98ejtserver
and the install at /opt/ejtserver.
The above buildIdv command will run the build, generate the installers, move all
relevant files (installers, docs, webstart) to conan. The following directories
will be created:
where <release_dir> is the version number with underscores (e.g. version 2.8 will be
in <release_dir> 2_8).
Then (see below):
Update the downloads/idv/toc.xml (see below)
Expand the javadoc (see below).
Generate the User Guide and Workshop PDFs (see below)
Update the index.html page (see below).
branch the git repository
change the /content/software/idv/current to point to the new release.
Update the downloads toc.xml page
On conan:
cd /content/downloads/idv
edit the toc.xml
- change the %version% property value
- change where the current and previous point to
change the current link to point to the new release.
cd /content/downloads/idv
rm current
ln -s <current IDV version> current
Expand the javadoc
cd /content/software/idv/<release>/docs
jar xvf ~ftp/pub/idv/<release_dir>/idv_javadoc_<version>.jar
cd docs
mv javadoc ..
cd ..
rm -rf META-INF/ docs
Generate the PDFs
You need to build the userguide.pdf and workshop.pdf files.
To do this you need to be on harpo (which has the htmldoc executable)
and run:
ant docs_pdf
from /share/idv/runtime
This will generate the userguide.pdf and workshop.pdf and place them in the
docs directory.
Note that ant may not be on your path. Look for it in
Look at the ant output and you will see where these PDFs are located.
Once this is done, copy them to conan:
Changing the index.html page
cd /content/software/idv/<release_dir>
cp ../<previous_release_dir>/index.html index.html.<release_dir>
edit the index.html.<version> file and update the IDV News and Announcements
section with information about the new release. Also edit the "Posted" date.
cp index.html.<version> index.html
(If you have to redo the release, index.html will get overwritten. That's why
we make the edits in index.html.<version>)
Open<release_dir> in a web browser.
Test all the links to the docs. Fix any broken links.
Branch the git repository:
After the release of a version, you should make a branch in the git repository
in case changes are needed later. To branch the git repository,
git checkout -b IDV_<version>
git push origin IDV_<version>
Update the current and stable links:
cd /content/software/idv
rm current
ln -s <current IDV version> current
cd release
rm stable
rm current
ln -s ../<current IDV version> current
ln -s ../<stable IDV version> stable (or simply point stable to current)
Go to the IDV homepage and make sure it is pointing to the updated directory. Make
sure all the links on the page work correctly.
Send out email to community:
Dear IDV User Community,
IDV XXXX is now available for download <>.
[Info about the release]
See the release notes <>
for a complete list of new features.
Best Regards,
The Unidata IDV Team
Running the test suite
Of course, running the tests should come first but it comes last in the README
due to its length.
The cliff notes version of this section, i.e., to run the full
test suite on the results of the build simply:
cd /share/idv/lib
tclsh /share/idv/test/runtest.tcl
And look at:
It is probably best to do this on harpo since the original archive images
are generated on harpo. This should minimize false differences.
The longer version:
The set of test archives are in:
Each archive has a directory there, e.g., dem, elnino, eta1, etc.
The script:
runs the set of tests. You can give it the full directory name of a
test archive to run just one test:
tclsh /share/idv/test/runtest.tcl /share/idv/test/archives/eta1
or as a short hand:
tclsh /share/idv/test/runtest.tcl eta1
If no archive directories are given on the command line it will run through
all of the archives in /share/idv/test/archives
The version of the idv that is used depends on where you are when you
run the test. If there is an idv.jar in the current working directory
then the script will run:
java -jar idv.jar
else it will run from the classpath:
java ucar.unidata.idv.DefaultIdv
The script will iterate through the test archives. For each on it will run
the idv in test mode and tell the idv to write to the <archive name>_results
directory. The script will then compare the generated images in the
original archive with the generated images in the _results directory.
The script produces 3 output files in the working directory:
results.html resultsLeft.html resultsRight.html
Results is a frame set that contains resultsLeft.html and resultsRight.html
Any stderr output is shown in resultsRight.html in red.
resultsLeft.html highlights the images that differ.
Note: We just do a "diff image1 image2" on the images. So
it is always the case that we pick up differences between some of the
To create a test archive enable the "Test" menu. There should be
a "Write Test Archive" entry. Select that and you will be prompted
for an archive name, an optional text description and the directory
to place the archive in. Select /share/idv/test/archives.
Building/configuring the installers
The installers are built automatically by ant using install4j which is
located in /share/install4j. We have a single, multi-platform license
which means that only one copy can run at a time, but on any machine
you want. Website for install4j is The
Unidata Admin staff has the license information. The license server
runs on abbott as of October 2011.
The configuration file is in git:
/src/ucar/unidata/idv/release/installer/idv.install4j. This file is used
as a template for the installer and copied to /share/idv/installers
during the build process. At that point, the version number is filled
To make configuration changes, run /share/install4j/bin/install4j and
open the template. After making changes, test the build and if it
works as you expect, save the changes back to the template.
JRE bundles:
The JREs that are included in the installers need to be updated
periodically as new versions of Java come out. This is an involved
process so set aside a day or two. Also have a spreadsheet ready to
keep track of your steps. For an example spreadsheet, see (use
emacs org mode to view it).
The platforms currently supported by the IDV are
- linux
- linux64
- solarisx86
- solarisSPARC
- windows
- windows64
- mac os x
On most platforms, it is a matter of:
- downloading the JRE from
- logging onto a machine of the particular OS
- unpacking the OS specific JRE to the appropriate subdirectory of /share/idv/jre
- installing Java 3D on top of the unpacked JRE (just unzip the version in the directory,
e.g., cd jre1.6.0_31; unzip ../j3d-1_5_2-windows-i586/
- running install4j to create a new JRE bundles. (Using install4j
creates smaller bundles than manually taring and gzipping the JRE
directory.) Also, you must run the install4j bundle wizard on the
specific OS for a given JRE bundle. You will have to obtain a login on
each of these platforms. Try to obtain logins on machines that have a
/share mount available to make your life easier. For example, ssh -Y
sparcMachine, and run /share/install4j/bin/install4j from that host.
The only platform that is problematic is Windows because when you
install the JRE, it makes the new JRE default on your system. To be
on the safe side, clear out any existing JREs so you have a fresh JRE
install. (Sometimes, cruft can accumulate over time in the JRE
directories.) Make sure you uninstall the JRE in a way that make
Windows happy, otherwise you will be cleaning up the registry. You
have to install it on your system, not to a temporary directory. You
also have to install a copy of install4j on your Windows system to run
the bundle generator. You can copy the c:/Program Files/Java/jre6 (or
where ever the JRE was installed) over to /share/idv/windows, unzip
the Java 3D on it and then pack it up using the Windows version of
To create a JRE bundle in install4j, start it up and select the
Project->Create a JRE Bundle menu (this menu item is not available on
OS X for install4j version 4 so don't tear your hair out looking for
it) and step through the process. The important page is the Select a
- select the top level of the unpacked JRE
- Input the version of the JRE (e.g. 1.6.0_20)
- For the custom id, use the java 3d version (e.g., j3d1.5.2)
NB: You will have to do this for every platform by running install4j
on each platform.
The resulting JRE bundle will use this to create a name like:
The JRE bundles are automatically stored in /share/install4j/jres (if
you are running install4j from /share/install4j/bin), except on
Windows. It will be stored in the jres directory of the Windows
install4j installation and then has to be manually copied over to
Once you have created the JRE bundles, you need to update the
install4j template to point to the new versions. There are two ways
to do this. The most fool-proof way is to run install4j and update
the Media instances to point to the new bundles. The other is just to
edit the template. If you do the latter, just make sure you change
all references.
SSEC uses install4j for McIDAS-V, so you can contact them for help
with the program. We also share the JRE bundles with them for
platforms that we don't have.
The Unidata admin staff has the information on licenses and passwords
to get in to download new versions.
Java Web Start Certificate Signing
On a yearly basis IDV Java Web Start certificate must be updated. Instructions
on updating that certificate can be found here
Java 3D Hosting.
As of September 2011, Oracle no longer hosts properly signed Java 3D jars necessary
for Java Web Start.
Unidata now host those jars here signed with our own certificate.
Please note that when the certificates expire it will be necessary to resign those
jarsigner -keystore file:///share/idv/.keystore -storepass XXXXX <jar file> idv
For the password, see the IDV ant build.xml.
Please see here for more information:
Jump to Line
Something went wrong with that request. Please try again.