Kepler

I have added two new tasks to the build system and two new targets. The first is the installer task which creates the install.xml file that IzPack needs to create the installer pack. The second task is the startupScript task which will create startup scripts for various OSs. Right now it only creates a .sh file but will eventually create a .app (for mac) and .exe and/or .bat (for windows).

The installer target first runs the startupScript task to create the script(s) then runs the installer task to create the install.xml file. It then runs the IzPack task to create the installer. Right now, the install.xml file only includes one pack for all OSs, but I have allowed the OS to be passed into the installer task so that it can create a custom install.xml file based on the individual needs of the various OSs (and to save space since some files should only be included for one OS or the other).

• Finish the startupScript task so it can create the .bat, .exe and .app startup files
• Finish the installer task to that it can create install.xml files for specific OSs
• Make the installer task smart enough to get exclude files not needed for a specific OS
• Make the installer task choose the appropriate startup file for the OS

You can try this task by using the 'ant installer' command.

Have run into all kinds of problems trying to make a Windows EXE file with our new module setup. Launch4J assumes that all of the code is in one jar file and builds an executable around that. I've automated the creation of the manifest file in the loader.jar file so that it includes all of the other kepler jar files. This mostly works, except that then all paths are relative to wherever you've issued the java -jar command, no matter where the loader.jar file actually is. This causes all sorts of problems with the way we're finding configs and the way that the MoMLParser wants to find the configs for the -kepler argument. I'm mostly going to punt on this for now, but will try to revisit it later. Spent three days on this with mostly nothing to show. I'll move on to creating the OSX .app directory, which should be much easier. Then we'll at least have a launcher for each os, even if the windows one is a .bat file for now.

Can't you do something like:
specURL = Thread.currentThread().getContextClassLoader()
.getResource(spec);

Or
this.getClass().getClassLoader().getResource(spec);

We use the code above in ptolemy.actor.gui.MoMLApplication and similar
code in ptolemy.util.FileUtilities to load resources in the classpath.
This works with Web Start and under Windows with jar files (I just checked).

The code that builds the exe is in ptII/adm/gen-8.0.

Interestingly, we are facing similar problems when trying to use OSGi.
The issue is that it is difficult to load resources in other jar files.

David created a bootstrapper that launches kepler and builds the classpath dynamically. The installer now makes full use of this bootstrapper. The scripts created with the 'ant startupScript' command also make use of the bootstrapper. When the installer is built, the startup scripts are also created and included in the installer.

Need to make the installer executable for windows.

Since R is now in its own module, the installer not only has to have the option to install R, but also to install the R module as well. Probably need to write a command line executable "module adder" so that the module can be included with the installer, then the installer can execute code to add the R module into the module manager.

Added functionality to the installer build task that allows it to pull in custom packs from modules. To use this, put an install.xml file in the module-info directory of the module. Any other resources needed for the install can also be placed there. For an example, see the R module.

Also added functionality for the installer to remove elements from the install.xml file with an 'os' attribute that does not match the OS that the current installer is targeted at. This will reduce the amount of time it takes to build the installer and the size of the produced installer. This will also allow us to automate the creation of OS specific installers.

The installer creation task has been working well for while. Closing this bug. If any other issues pop up, new bugs will be opened.

Re-opening. forgot so many bugs blocked this one.

All dependent bugs are now closed. The installers are easily built with the modular architecture. Closing this bug.

Original Bugzilla ID was 3949