JNode Installer proposal

Name of the submitter:
Valentin Chira

Goal of the proposal:
Unify the way modules are installed / maintained in JNode. By “module” one must understand any application, library, driver or plug-in.The installer repository must be also used to lunch installed applications.

Functional description:
The Installer should serve as a main administration tool for the installed modules and as a tool to be used to install new modules in JNode. One of the modules should be JNode itself. Each module definition must be a list of its sub-modules, own files, external library references (needed to run the module), security requirements, external installer, etc. The user must be able to interact with the installer through a “command line”/”graphical” interface and perform administrative operations like updating a module, installing new modules or removing a module. For ease of use the user must be able define “modules clusters” and aggregate more modules in a cluster. For example one of this clusters can be called “system” and be JNode itself. One important function that the installer must support is version administration for modules. The installer must support the administration of modules at the level of version so that multiple version of the same module can be installed. The first “use case” for the installer is JNode installation itself. The JNode installation should consist of installing a minimal JNode version on the HDD edit the “system” cluster modules list and than call the installer to update/install the modules from the list, ex: “installer –u system”.

The installer module should be based on a standard Java technology. This is why I believe we should use JNLP which offers a standard way to install modules. The installer should be a JNLP client that has a cache/repository attached. The Installer should cache the JNLP files for all installed modules and also keep an index file for the installed modules. I propose that this index file to be an xml file called “index.xml”. The storage representation should look like this:


The index.xml file will contains at least one entry for each installed module and all created clusters. This is should look pretty much like a database(maybe we could use here a small xml database engine). The index file is loaded at first use of the installer and should be cached in memory. The index.xml structure should be something like this:


The process of installing a new application should be no more than downloading the jnlp file, copy the files described there and than modify the index.xml file to add the new installed application. Here we could have problems if another application with the same name is installed. In this case I think we should just ask the user for an alternative name. Maybe in the index.xml we could store not just 1 name but 2: originalname="app1" and name="editor". In this way one could install applications with the same jnlp name. A trickier problem is version handling.

The most important operation that the installer must support is updating the packages which are already installed. This operation must care for all dependant packages and should start by downloading the new jnlp file into a temp folder. Let’s assume the following scenario:
The user runs in console the following command:

"/> installer –u system"

What the installer should do first is find what is associated with name system. Lets say that system is a cluster of modules than the installer should update all modules from “system” cluster. This means finding all the modules that belong to this cluster or sub-clusters read their updateURL entry and download the new JNLP files and execute them. In the process of installation of a new version the installer must check if the external resources of the new version have the version described in the JNLP file and if they don’t than this resources must be updated as well. The update of resources must be done only if no other module uses the current version of the resource. In our example lets say that module service-manager has a new version which needs ant version 1.6 but locally we have ant 1.5 installed than ant must be updated as well if no other modules use ant 1.5. If ant 1.5 is still used than the new version of ant must be installed separately and the old version kept.

Sun JNLP specification
Portage application developed for Gentoo Linux distribution


markhale: Details on use of JNLP files.

Three types of modules have been identified; applications/applets, libraries and system level plugins (includes drivers). The purpose of this note is to detail how each type of module is described by a JNLP file.

Well-known description using application-desc or applet-desc.
Using component-desc.
System plugins
Propose the introduction of jnode:plugin-desc. To do: give a mapping of existing plugin xml to jnlp xml. import->part,export->package???

To allow for finer-grain control of security, introduce jnode:permission child element of jnlp security element.
jnode:permission will have the following required attributes: class, name, actions.


Hi Valentin, good work in this Document.
In this mode the JNode Installer will be a good Tool.

I still have some questions/reflections for you:
- this Installer should be the ONLY way to install/Update/Remove packages in JNode, and also to GRANT the executable flag to jar and (main) classes contained ... but for Shell scripts ? So from his Console we could disable/enable some Applications to work, and query to know what Applications are Installed in the System
- all should work in a Role-based Security, like Tomcat (Users, Groups and Roles), where to add/remove something Global to the Pc must require the current user to have the "Admin" Role or something similar. For example, any JNode package must belong to this behavior (plus digitally signed jars).
- depending on the Category of the Package ("Cluster" in your terminology ?) is the Installer that set where to install, and NOT the Package itself
- standard categories, like that in Gentoo or in RPM ?
- the Installer could have some commands to merge packages, like creating symbolic link to jars in the global area, but attention: we MUST avoid Windows-like dlls ...

- any package in this format should have also these features:
* vendor name, site, download link,
* name, version, filename,
* checksum (PGP, MD5, etc.) to identify any jar not only by file name
* grants to ask to the user (for creating Desktop icons, opening socket, etc.)
* role needeed to execute the Application
* how to manage locale-dependent resources (for the various languages) ? From here, or any Package will be responsible for this ?
* etc ...

- index.xml, shouldn't it be better to have only in it some pointers to separate clusterNameX.xml files, and also in subdirs for AllUsers and UserX ?

- UpdateURL for the Packages, is the JNode Site compatible with a Mirroring model (like that in SourceForge.net) ? And how to achieve this in the UpdateURLs ? With susbtitution variables, like $(JNODE_SITE) ?

- installer command-line flags for:
* list packages, with and without dependencies
* check dependencies
* mark to not remove
* clean (all unreferenced packages)
* regenerate dekstop icons (if any)
* etc ...

- the final Release of JNode si going to be installed like Gentoo Linux ? Boot from Cd/Lan, HW discovery and config, fdisk/format, install Base packages, then others, bootloader, etc., and finally reboot ...

I Hope these comments will be useful to someone.


version of package

I would like to add something about package version :

- with each dependant package, we should have minimum version required

- but sometime a dependant package may break backward compatibility (refactoring ...) . So, we should handle this case and choose between :

* keep 2 versions of the same package : isolation of packages

* OR not update to the latest version

I found on sourceforge a project named JRPM that is an implementation of RPM in JAVA (but not fully implemented yet).

If we need something compatible with RPM this could help (I don't know much about RPM).