I have address the fact that SourceForge disabled the interactive shell, which we mainly used to edit the DrJava website, by creating a mirror of the DrJava website at http://www.cs.rice.edu/~javaplt/drjava/ (something we have inconsistently done in the past), editing the website on CSnet, and then using rsync to transfer them to our SourceForge website at http://drjava.org/.
To do that, I created a javaplt SourceForge account, set up password-less login into SourceForge from javaplt on CSnet, and updated our mirror on CSnet for the DrJava website that we have on SourceForge. Both websites have the same content now.
Changes to the website should be made on CSnet in /home/javaplt/public_html/drjava/.
You then need to copy your changes to the SourceForge website by running the drjava-cs-to-sf script I created (located in ~javaplt/bin, but it’s on the path for the javaplt CSnet account). This script does an rsync to transfer all modified files to SourceForge. Files that do not exist on CSnet anymore but are still present on SourceForge are deleted.
There is also a script that copies in the opposite direction, from SourceForge to CSnet: drjava-sf-to-cs (also located in ~javaplt/bin). Because we should consider the CSnet site our primary location for editing, drjava-sf-to-cs makes backups of deleted or modified files in /home/javaplt/public_html/drjava/.backup/. We should clean that directory occasionally, but it is excluded from drjava-cs-to-sf, so the backed up files never end up on SourceForge.
To do a dry-run without copying, you can pass the --dry-run argument to the scripts; to force all files to be copied (ignoring time stamp and size), you can pass -I. Example: drjava-cs-to-sf --dry-run -I.
I have also updated the update-news script that we had on SourceForge. It is now called drjava-update-news (also located in ~javaplt/bin). It updates the news on CSnet and then copies only that file to SourceForge.
