We have had a GUI installer for Windows for a few releases now, and it seems to be quite successful.
It uses installjamemr which seems to work reasonably, but there are a couple of small problems with it, like not displaying the full name of the projects directory correctly.
The release mechanism for building the windows installer could do with being improved as it still has several manual steps, partly becomes installjammer doesn't seem to be able to pick up its file groups using a relative path name.
One option is to produce GUI installers for Linux and MAC OS X. InstallerJammer should be able to do this from a single configuration file, but it would be more things to test whn doing a release.
One way of improving Linux installation would be to create packages. A user on the forums did this a while ago and it seemed to work smoothly. It can automate the installation of dependent packages.
One issue with this is that there are different package formats for different Linux distributions, and there is also an issue of which repositories we could put leJOS in.
Brian has expressed the opinion that we should install into IDEs and have no separate leJOS NXJ installation. However, this does not seem to be the consensus opinion.
Issuing source and projects
We currently issue all the Java source as Eclipse and Netbeans projects. Sven has questioned whether this is a good idea for anything other than the samples.
There is an issue that using the projects doesn't work well unless the whole set is in the same directory (or workspace) as they have dependencies on each other and use relative paths. Theere are also duplicate copies of the jar files in eacxh of the projects.
We issue the API docs in the doc directory of these projects (as well as on the web site). This might not be best practice.
Issuing the projects in this way does make it easier for users to look at them and modify them in IDEs, but this is a two-edged sword.
We currently issue the C source in a src directory. There are options either to issue this as C projects for the Java IDEs (i.e. CDT for Eclipse) or to issue it as zip files.
There are several things we could do to simplify installation, such as:
- Getting rid of the need for environment variables
- Getting rid of the need to add to the PATH
- Improving property handling
- Including JNI libraries in jars
- Including firmware binaries in jars
Getting rid of the need for environment variables
There was a recent discussion about getting rid of the need to NXJ_HOME. The scripts can deduce it from what is on the PATH, but there are still several uses of it from plugins and ant build scripts.
Getting rid of the need to add to the PATH
This is probably harder for the command line tools. We require the JDK bin directory on the path so that we can call "javac", but the Sun installer does not put it there. This is a source of error.
Improving property handling
The nxj.properties file should not be in the bin directory and it probably should not be part of NXJ_HOME at all, as it should be read only. The only current use is to define which comms drivers to use and most of the time the defaults are fine.
Including JNI libraries in jars
Bluecove does this, but it it is not very good practice. It would make things easier for the Eclipse plugin if we did this and remove one use of NXJ_HOME and one of the reasons to put things on the path.
Including firmware binaries in jars
Another option is to put lejos_nxj_rom.bin and StartupText.bin in a jar file, such as pctools. If we did this and put JNI libraries in the jars, we would have hardly any need for a bn directoy.