DrJava Build and Release Instructions

As part of our knowledge (back) transfer, I wrote up these instructions for creating a fresh build of all parts of DrJava and then making a new release on SourceForge.

Note: Our build process is currently broken for Windows machines (see
“instructions below for building just DrJava”, step 6, “Make the
release and put it into Subversion”.)

  1. Check out trunk (svn co https://drjava.svn.sourceforge.net/svnroot/drjava/trunk), or if you have trunk checked out, update it.
  2. cd drjava
  3. ant clean jar
  4. cd ../platform
  5. export DRJAVA_JAR=../drjava/drjava.jar
  6. ant clean compile-??? jar

    Note: Which compile-??? targets you can run depends on the platform
    you are compiling on. You need to be on a Mac to run compile-mac and
    on Windows to run compile-windows. Since the compiled classes are
    stored in Subversion, you can always do

    ant clean jar

    to just get all the class files without recompiling.

  7. cp platform.jar ../drjava/lib
  8. cd ../plt
  9. ant clean test jar
  10. Copy the generated new plt.jar file over all other plt.jar files.
    This can be done using

    find .. -name plt.jar -not -samefile plt.jar | xargs -n 1 cp -v plt.jar

  11. cd ../dynamicjava
  12. ant clean test jar-base
  13. cp dynamicjava-base.jar ../drjava/lib
  14. cd ../javalanglevels
  15. ant clean test jar-base
  16. cp javalanglevels-base.jar ../drjava/lib
  17. cd ..
  18. Continue with the instructions below for building just DrJava, but not
    plt.jar, etc. from scrach.

Building the DrJava application (not the libraries) and making a new release:

  1. cd drjava
  2. Create the release locally. It’s a good idea to do this first, without touching Subversion or SourceForge. To create a development release:
    ant clean release-local
    To create a beta release:
    ant clean release-local-beta
    To create a stable release:
    ant clean release-local-stable
  3. This cleans, compiles, runs the unit tests, builds the jar, exe and
    Mac application, and it also generates the Javadoc and a zip file with
    source code.
  4. It makes sense to test the three different variants of DrJava: Run
    the jar on some platform, run the exe on Windows, and run the Mac
    application on a Mac, because sometimes one of them may be corrupted.
    This can has happened sometimes for the exe file when building on a
    Mac, or for the Mac application when building on Windows or Linux.
  5. ant clean
    This deletes the locally built release again.
  6. Make the release and put it into Subversion. Run one of:
    ant release
    ant release-beta
    ant release-stable

    You may want to add -Dtest-repeat=0 to the command line (e.g. ant
    -Dtest-repeat=0 release
    ). That tells Ant not to run the unit tests.
    You can leave it out, but we just ran the unit tests, so it should not
    be necessary to run them again.
    Note that this step may ask you for your SourceForge password if you
    have never committed code to Subversion from the computer you are
    working on.

  7. The build script will now create a “tag” of DrJava that will
    contain exactly the source code versions and libraries used to build
    this release of DrJava. This is useful in analyzing bugs that users
    report in a specific version.
  8. Make note of that tag. It should be something like this:
    drjava-20110205-r5425
  9. To upload files to SourceForge, we will follow this guide written by SourceForge. I find that using SFTP is the easiest.
  10. Log into SFTP. In the following command, replace <username> with your SourceForge username:
    sftp <username>,drjava@frs.sourceforge.net
    Example: sftp mgricken,drjava@frs.sourceforge.net
  11. On the SFTP server: cd /home/frs/project/d/dr/drjava
  12. If you are building a stable or beta release, type:
    cd "1. DrJava Stable Releases"
    If you are building a development release, type:
    cd "2. DrJava Development Releases"
  13. Create a directory with the name of the tag from step 8 above.
    Example: mkdir drjava-20110205-r5425
  14. Change into that directory.
    Example: cd drjava-20110205-r5425
  15. Upload the files. You can do that with the command:
    put <tag>*
    Example: put drjava-20110205-r5425*
  16. Exit SFTP:
    exit
  17. Browse to DrJava’s SourceForge site at
    http://sourceforge.net/projects/drjava/develop and log in.
  18. Click on the “Files” tab (or go to
    https://sourceforge.net/projects/drjava/files/).
  19. Click on 1. DrJava Stable Releases or 2. DrJava Development Releases, find the tag, and enter that directory. You should see the
    files you uploaded.
  20. Click on the (i) (Info) button next to the exe file, check the
    Windows checkbox, and press save.
    Click on the (i) (Info) button next to the Mac application, check the
    Mac checkbox, and press save.
    Click on the (i) (Info) button next to the jar file, check all the
    other checkboxes (except Windows and Mac), and press save.
    This step changes the default download on DrJava’s SourceForge page
    (in the “Download Now!” button on https://sourceforge.net/projects/drjava/). People downloading
    directly from the SourceForge page will start getting the new release.
  21. Prepare the release notes text file called readme.txt. I start
    with a template that looks like the one below. To determine the lists
    of new features and bug fixes, you can look up the revision number of
    the last release you’re comparing to, and then you can go through the
    Subversion log and look at the descriptions of the commits, which
    should hopefully be good enough to tell you what was done. Unless the
    last version was a stable release, I usually include a comparison to
    the last stable release as well, which is easy to create just by
    copying and pasting the lists from individual release notes together.


    Available for download at http://drjava.org  .
    
    DrJava is a lightweight programming environment for Java designed to
    foster test-driven software development. It includes an intelligent
    program editor, an interactions pane for evaluating program text, a
    source level debugger, and a unit testing tool.
    
    In addition to bug fixes, this  release
    includes a number of new features introduced after the last
     release:
    
    
    
    Note: Java 1.4 compatibility has been dropped. To use DrJava, you will
    need Java 5 or newer.
    
    
    New features since the last  release:
     - list of new features since the last beta/development release
    
    
    
    Bug fixes since last  release:
     - list of bug fixes since the last beta/development release
    
    
    
    New features since the last stable release:
     - list of new features since the last stable release
    
    
    
    Bug fixes since the last stable release:
     - list of bug fixes since the last stable release
    

  22. On the DrJava SourceForge page, upload the release notes into the
    new release’s folder. You can do that either using SFTP again or using
    the web upload by clicking on “Add File”. I just find that SFTP works
    better for uploading the multiple large files earlier in step 15.
  23. On the DrJava SourceForge page, hover over “Develop” and click on
    “News” (or go to https://sourceforge.net/news/?group_id=44253, but that link has changed frequently). Click on “Submit” and paste the contents of the readme.txt file into the “Details” part. In the “Subject” line, I usually put something like “DrJava Development
    Release 20110205-r5425”. Press “Submit”.
  24. Send an email to the following addresses: drjava@rice.edu,
    drjava-hackers@lists.sf.net, drjava-users@lists.sf.net
  25. I use the same text that was used in step 23 for the SourceForge news,
    but I let the following text precede the email:


    Dear DrJava Users:
    
    We have made a new <stable/beta/development> version available: <tag>
    
    You can download it from the DrJava website at http://drjava.org/
    or from SourceForge.net by following this link:
    
    <link>
    
    You receive this email because you have subscribed to a DrJava mailing list.
    

    Replace the <link> part with the link to the SourceForge page that has
    the files for this release, i.e. the website you navigated to in step
    19. Example: https://sourceforge.net/projects/drjava/files/2.%20DrJava%20Development%20Releases/drjava-20110205-r5425/

  26. SSH into CSnet as javaplt (e.g. ssh javaplt@finland.cs.rice.edu).
  27. cd ~/public_html/drjava
  28. Run the drjava-update-news script. This pulls the SourceForge news
    onto the DrJava website. Note that for now, this only happens on our
    CSnet mirror at http://www.cs.rice.edu/~javaplt/drjava/
    drjava-update-news
  29. Edit the LATEST_DEV_VERSION.TXT, LATEST_BETA_VERSION.TXT or
    LATEST_VERSION.TXT file, depending on whether you have a development,
    beta, or stable version. Put the new tag into the file. Make sure
    there is no newline at the end of the file!
  30. If you made a stable release, you will want to remove the download
    links for the beta and development releases. Edit main.shtml and
    change the line

    <!--#include virtual="beta.shtml"-->

    to

    <!--include virtual="beta.shtml"-->

    and

    <!--#include virtual="devrelease.shtml"-->

    to

    <!--include virtual="devrelease.shtml"-->

    If you made a beta release, you want the hash mark for the #include of
    the beta.shtml file, but not for the devrelease.shtml file. If you
    made a development release, you probably want the hash mark for the
    devrelease.shtml file, but not for the beta.shtml file.

  31. Do a similar thing as in step 29 for download.shtml. The
    corresponding lines are

    <!--include virtual="beta_long.shtml" -->

    and

    <!--include virtual="devrelease_long.shtml" -->
  32. Go to http://www.cs.rice.edu/~javaplt/drjava/ and check that the
    download buttons link to the right files, the ones that you have just
    released. It’s a good idea to download them all and run them, to make
    sure there were no upload errors.
  33. Delete backup files:
    rm *~
  34. Copy the website to the SourceForge server using the
    drjava-cs-to-sf script. Note that it may also update Javadocs, test
    coverage, and other files.
    drjava-cs-to-sf
  35. That’s it! Thanks for helping make DrJava even better.
Share

About Mathias

Software development engineer. Principal developer of DrJava. Recent Ph.D. graduate from the Department of Computer Science at Rice University.
This entry was posted in DrJava. Bookmark the permalink.

Leave a Reply