Last updated on: 07/23/02

Assumptions

The following applications and/or OS are assumed to be available to the development team.

 

  1. Borland JBuilder for development/debugging
  2. Rational ClearQuest for bug tracking
  3. Microsoft Visual SourceSafe for version control management
  4. Apple Macintosh is available for JBindery.  The preferred OS is OS 9.2.2.

If any of the above product/OS are absent, a suitable and documented substitute should be used instead.

Checklist for artifacts in every release

All of these artifacts should be in HTML, Microsoft Word or RTF format and reside in the main folder of the WorldBuilder archive.

 

  1. This document
  2. Extensibility document
  3. User manual document
  4. What’s new document
  5. Install instructions document
  6. Check-in email template

Release activities

All activities should be done on a Windows platform, unless stated otherwise.

 

  1. Complete all check-ins that are going to be going into the upcoming release.  This includes sending out all check-in emails and resolving all pertinent bugs.

 

  1. Get the latest sources from SourceSafe.  Right-click on NASA/m1 folder and select Get Latest Version… command from the context menu.  In the dialog that comes up, check Recursive and uncheck Make writable.  Double check that there any no temporary .java files left in any source folders.  Delete temporary .java files.

 

  1. Delete all .class files in classes\wb subfolder of the project.  In command prompt when the current folder is the main project folder, the command looks like this: del /q /s classes\wb.  This command is necessary to ensure that only files that came from SourceSafe will be built.

 

  1. Build the entire project using the latest sources in JBuilder.  The build process will place the newly built .class files into classes/wb subfolder.

 

  1. Update resources.txt with new version number.  This is a text file that can be edited with any text editor.  The version key should have the version number of the upcoming release.   Usually a minor version increment is sufficient, e.g. 1.1.5 to 1.1.6.

 

  1. Determine all the bugs/workitems that were fixed in this release.  There currently is no automated way of getting the list of bugs fixed for one release from ClearQuest.  Check-in mails sent between this release and a previous one serve as a manual substitute for the time being.

 

  1. If necessary, update the appropriate artifacts from the checklist.  At the very least this includes What’s new document.

 

  1. Run m1_make.bat to create the release bundle.  See Notes on working with m1_make.bat below for more information and instructions…

 

  1. Update the version number on the website in \\dogbert\nasa\wwwroot\default.htm.  Also, don’t forget to update the Recent News section in the same file.  This version update should match the version set in step 5.  If some of the artifacts are published on the website as well, they too need to be updated along with corresponding entries in Recent News section.

 

  1. Label the project being released in SourceSafe.  Label is the command in SourceSafe. The label should match the version set in step 5.

 

  1. Send release email to all project constituencies.  At a minimum, release email should state the new version in the title and include the list of bugs that were fixed in the release in the message body.

 

If the structure of WorldBuilder application changes

If the structure of WorldBuilder application changes, it may be necessary to recreate mac_exe.zip file.  mac_exe.zip holds JBuindery executable for Macintosh OS9 platform.  JBindery executable needs to be enveloped in an archive file because exposure to a Windows environment damages the file and it is not longer recognized when brought back into the Macintosh environment.  JBindery executable assumes that the main class in WorldBuilder.jar is wb.WorldBuilder and that Tidy.jar is located in the same folder as WorldBuilder.jar.  If any of these assumptions are violated mac_exe.zip needs to be recreated.  Use the following procedure to accomplish this goal:

 

(Mac OS9 or Mac OS X in classic mode)  Copy WorldBuilder.jar and Tidy.jar to Macintosh.  Email, or web folders is the best way to move files across platforms.  Using JBindery from MRJ SDK 2.2 create JBindery executable file.  In JBindery, you’ll need to specify that wb.WorldBuilder is the startup class and add Tidy.jar to the classpath.  Then save the resultant executable to disk with name WorldBuilder.  Place WorldBuilder executable into an archive.  This is easy to do by dragging WorldBuilder icon and dropping it over DropZip application icon.  DropZip application is usually located in Macintosh HD: Applications (Mac OS9): StuffIt Lite 6.5.1.  If DropZip is not found in that location, use Finder to locate it.  After an archive is created (under name WorldBuilder.zip) you will need to rename it to mac_exe.zip and transfer back to the Windows build machine.  The new mac_exe.zip should replace the old one.

 

Note: JBindery is a part of MRJ SDK 2.2.  Before you install the SDK, you will need to install MRJ 2.2.5.  For downloads and to find more information, refer to http://developer.apple.com/java/classic.html.

Notes on working with m1_make.bat

m1_make.bat requires several environment variables that can be unique to each developer’s environment.  To support this flexibility, m1_make.bat will call each developer individual settings file.  The name of the file is %username%.bat, where %username% is an environment variable set for the currently logged on user.  If you don’t know your %username%, go to command prompt, type set and you’ll find the value in the output list.  As a development manager, I ask all team members to check in their environment files into NASA\env folder in SourceSafe.  In that folder you can already find examples of environment files from some developers.  To get a better idea about its content, below is Andrew’s file: apg3.bat:

 

@echo setting environment variables for %username%

 

set j2sdk="c:\j2sdk\bin"

set m1_main="D:\My Documents\CMU\_2002 Spring\17-672 Software Development Studio II\m1"

set m2_main="D:\My Documents\CMU\_2002 Spring\17-672 Software Development Studio II\m2"

 

Note: depending on your platform you may not need the quotes around the paths.  Windows XP seems to require the quotes, while Windows 2000 seems to work without them.

 

Both .bat files (m1_make.bat and %username%.bat) should reside in the root folder of the project project.  Additionally, you’ll need to get manifest.txt from NASA\env folder in SourceSafe.  This file should go into classes folder.  If configured correctly, running createM1Jar.bat will generate WorldBuilder.jar.  This file will reside in classes folder.

Notes on debugging m1 in JBuilder

If you wish to debug m1 software, you’ll need to copy WorldBuilder.jar and Tidy.jar to the folder where m1 JBuilder project file is located before you start the debugging session.  You will need to repackage WorldBuilder.jar for each modification you make.  Use m1_debug.bat to prepare the debugging session.

 

Important: Do not forget to delete WorldBuilder.jar and Tidy.jar from the project root folder before you start the release process in particular before you run m1_make.bat.

 

Note: Running m1_debug.bat is necessary for WorldBuilder.FILE_THISJAR constant to be processed properly and will also guarantee that SimObjectFactory.getPackageClasses() will find the objects inside wb.simobjects package.  If after running a valid storyboard, you get the message that (only) 2 objects were processed at the end, it means that you do NOT have it configured properly and you will need to verify that the two .jar files are in the project root folder.