Bug #3949


Get the installer working with the new build system

Added by Chad Berkley over 14 years ago. Updated over 14 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 executableResolvedChad Berkley06/05/2008

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Actions #1

Updated by Chad Berkley over 14 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.

Actions #2

Updated by Chad Berkley over 14 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.

Actions #3

Updated by Christopher Brooks over 14 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.

Actions #4

Updated by Chad Berkley over 14 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.

Actions #5

Updated by Chad Berkley over 14 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.

Actions #6

Updated by Chad Berkley over 14 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.

Actions #7

Updated by Chad Berkley over 14 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.

Actions #8

Updated by Chad Berkley over 14 years ago

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

Actions #9

Updated by Chad Berkley over 14 years ago

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

Actions #10

Updated by Redmine Admin over 10 years ago

Original Bugzilla ID was 3949


Also available in: Atom PDF