Bug #3949

Get the installer working with the new build system

Added by Chad Berkley over 13 years ago. Updated about 13 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


The build system needs to be able to create an IzPack installer for the standard modules to install the core of kepler. This should be able to work on windows, osx and linux. Windows vista should be tested as well as XP.

Related issues

Blocks Kepler - Bug #3369: Kepler will not start (OS X 10.52) as JavaApplicationStub is not executableResolved06/05/2008

Blocks Kepler - Bug #3483: case sensitive Leopard install failsResolved09/05/2008

Blocks Kepler - Bug #3097: incorrect classpath in generated and momlexecute.shResolved01/23/2008

Blocks Kepler - Bug #3251: Installer Splash Screen should be an HTML WidgetResolved04/30/2008

Blocks Kepler - Bug #3242: dlls should not go in c:/Windows/System32Resolved04/24/2008

Blocks Kepler - Bug #4013: Make sure duplicate jars are not included in the installerResolved04/22/2009

Blocks Kepler - Bug #3734: Some demos no longer work after new build/reposResolved01/08/2009

Blocks Kepler - Bug #3967: Unable to run java -jar kepler-trunk.jar with -nogui -nocache -runwf fullworkflowpath optionsResolved04/08/2009

Blocks Kepler - Bug #3074: Code library installation issuesResolved01/16/2008

Blocks Kepler - Bug #4015: Add 64 bit disclaimer to installerResolved04/22/2009

Blocks Kepler - Bug #4016: Test IZPack Installer on 64 bit machineResolved04/22/2009

Blocks Kepler - Bug #3809: jni actors do not workResolved02/05/2009

Blocks Kepler - Bug #4017: Make sure module manager and installer work together wrt the classpathResolved04/22/2009

Blocks Kepler - Bug #4018: Remove non-2.0 functionality from 2.0 releaseResolved04/22/2009

Blocks Kepler - Bug #4026: Bootstrapper will not run kepler in a directory with spacesResolved04/24/2009

Blocks Kepler - Bug #4063: Kepler-1.XDev Installer is largeResolved05/13/2009

Blocks Kepler - Bug #4064: remove r installer after installation is completeResolved05/13/2009

Blocks Kepler - Bug #4060: Copyrights need to be updated to 2009Resolved05/12/2009

Blocks Kepler - Bug #4061: Documentation links are not activeResolved05/12/2009

Blocks Kepler - Bug #4065: Copy documentation into installerResolved05/13/2009

Blocks Kepler - Bug #4067: Add "about" widget for kepler on the macResolved05/14/2009

Blocks Kepler - Bug #4159: Cut 2.0-alpha/SanParks releaseResolved06/15/2009


#1 Updated by Chad Berkley over 13 years ago

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).

Remaining tasks to do are:
  • 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.

#2 Updated by Chad Berkley over 13 years ago

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.

#3 Updated by Christopher Brooks over 13 years ago

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


We use the code above in 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.

#4 Updated by Chad Berkley over 13 years ago

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.

#5 Updated by Chad Berkley over 13 years ago

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.

#6 Updated by Chad Berkley over 13 years ago

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.

#7 Updated by Chad Berkley over 13 years ago

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

#8 Updated by Chad Berkley over 13 years ago

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

#9 Updated by Chad Berkley about 13 years ago

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

#10 Updated by Redmine Admin over 9 years ago

Original Bugzilla ID was 3949

Also available in: Atom PDF