cornercorner
FeaturesPluginsDocs & SupportCommunityPartners

Installation Structure

$Revision: 1.4 $
Changes: available in CVS or in older CVS

Abstract:

NetBeans installation structure shall smoothly fit into host operating system (the correct packaging) and shall support multiple products that are build on top of NetBeans platform and provide sufficient framework for compatible development of every product part. This document summaries the requirements and describes sample ways to achieve them. After reading it you should understand why the installation structure of NetBeans 4.x looks the way it looks and also realize what is the best structure and packaging for your NetBeans platform based product.

Requirements

  1. There is more products based on NetBeans (NetBeans IDE, S1S Enterprise Product, S1S Mobile Product, NetAct, mc4j, etc). That means more separate installations. But the installations shall not duplicate any files, instead they shall share common files between themselves as well as other components in the system.

    This means that we shall use system delivered xerces, javahelp and that there should be just one core.jar and other NetBeans components installed.

  2. The layout of files shall match OS conventions. So bin shall contain just binaries, the files modifiable by system administrator shall be in /etc directory, etc. See issue 32080.

  3. Support for relocatable installations. One shall be able to install the package on server and mount it on client machines (usually to different location). That means the installation cannot contain hardcoded fully qualified paths.

  4. Handle incompatible versions. Evolution of any part of the product cannot hurt compatibility expectations of other parts. When a new version of NetBeans IDE Product is installed, other products like Mobile Product has to continue to work.

  5. Relation to AutoUpdate. Different installation methods (RPM packages, AutoUpdate) shall not clash.

Content

  1. Supported Installation Scenarios
  2. Target systems and Logical Layout
  3. Generic Launcher
  4. Versioning of Clusters
  5. Real Layouts
  6. User Directory Layout
  7. Influence on other parts of the system

Supported Installation Scenarios

There is a few different, disjoint, ways how NetBeans or any other product based on NetBeans can be installed:
  1. (Recommended for most Unix users) Install the appropriate packages from your favorite update channel or downloaded from netbeans.org or shipped to you on CD or whatever, in RPM format or similar. Run. If updated packages become available, install them as you would any other software on your operating system. If you like, get extra packages from an "optional" set of less-frequently-used packages. All modules included in the NetBeans Product you are running are enabled. (They had better not do work on startup or suck up RAM or clutter the UI. If they do, they are not product quality.)

  2. (Recommended for casual Windows users, and curious but noncommittal Unix users) Go to netbeans.org and click "Launch NetBeans in Web Start". Have fun (this is under development). A big enterprise might also put a custom configuration on their intranet (available at installer pages).

  3. (Recommended for most Windows users, some power Unix users, and NB developers) Download the ZIP (or .tar.gz or .tar.bz2 or perhaps .exe installer) of NetBeans. Unpack and run. If you want to turn some modules on or off, or get some new modules, or uninstall some modules, or stick some modules in your user directory so you can try them without making changes to your installation, etc., select Tools -> Update Center and go for it.
Each of this scenarios is targeted to a different set of users and provides some behaviour that other lacks (usage of native package manager, ability to launch from web browser, connection to autoupdate). Not all functionality is available in every scenario, there are things that we explicitly do not want to support:
  • Autoupdate and native packaging has to stay separated. It is not possible for autoupdate to modify or upgrade packages that have been installed by native packager. Both methods can coexist under the assumption that they both update completely different files/directories.

  • Any user-mode module management when using Web Start. If you click on the .jnlp file, you get some enabled modules; take it or leave it. If you want a different config, set one up - there should be tools available for power users and sys admins to easily create customized NB configurations for JNLP.

  • Explicit module management (Tools -> Options -> Modules) as part of the core UI. This should be a feature of Auto Update, if that is installed (i.e. on Windows or Unix in evaluation mode), and properly integrated with the update functionality (so that Delete really uninstalls NBMs, see issue 20323, etc.).

Solution

Target systems and Logical Layout

 We want to provide RPM packages for Linux, Solaris packages for Solaris, some Windows installer and WebStart support for direct download. These variation has to respect the OS rules, but otherwise be as close as possible to each other to simplify crossplatform maintanence problems. In order the hide the differences between various platforms and also to describe the common root for layout on each individual platform, we start with a definition of a logical layout of the idealized installation structure.

Because of the requirement to have different products based on NetBeans we have choosen a solution based on multiple installation directories (for discussion see issue 27151). Different products are composed from a set of clusters. There will be a NetBeans Platform, NetBeans IDE, NetBeans Enterprise, and NetBeans Branding clusters. They will then be composed into related products:

  • NetBeans IDE Product - contains the base NetBeans Platform cluster, two clusters providing the basic IDE functionality - NetBeans IDE cluster and NetBeans Enterprise cluster. Moreover it will have its own branding and other non-library parts in its own NetBeans Branding cluster.

  • Native Product - contains NetBeans Platform cluster and the NetBeans IDE cluster but it does not include NetBeans Enterprise cluster as it does not need the functionality at all. The own additions of the product are in its own Native cluster.
Each cluster has its own install directory ($nbplatform, $nbide, $nbenterprise, $nbweb and $nbnative) with a following structure:
  • lib: contains native JNI libraries and basic boot files. The naming policy of the libraries is in hands of the modules, as that it has worked well enough till now. If it proves unsufficient following conventions shall be obeyed: There are subdirectories under the lib directory that reflect the architecture (e.g. i386, obtained via System.getProperty ("os.arch")) and possibly also subdirectory identifying the system (e.g. i386/linux, obtained via System.getProperty ("os.name").toLowerCase ()). When the system is looking for a particular library it scans the deepest directories first and then the shallow ones (lib/i386/linux, lib/i386, lib).

  • core: contains JAR files that will be placed into the dynamic system classpath when the NetBeans based system is starting.

  • modules: contains directories and subdirectories with modules. Usual convention is to name module according to its code name base (e.g. org.netbeans.modules.html will be in JAR file org-netbeans-modules-html.jar) and if the JAR uses Class-Path entry, then put such extension into ext/ subdirectory.

  • config: is a place where configuration data are being stored like Modules/ directory, etc. A view of this directory is visible as Repository.getDefaultFileSystem() from inside running NetBeans system.

  • docs: a directory dedicated to documentation, release info, credits.
Different clusters may contain additional directories under their $nbcluster. Their standardization is beyond the scope of this paper right now with the exception of generic platform launcher.

Generic Launcher

 The $nbplatform cluster is guaranteed to contain $nbplatform/lib/nbexec executable that is supposed to be used by final products. Example:

The NetBeans IDE product should provide its own executable /usr/bin/netbeans which will locate the $nbplatform/lib/nbexec (currently implemented here for unix and here for windows) executable, read their own configuration files, find out locations of additional clusters and pass --clusters /pathto/nb4.0:/pathto/ide4:/pathto/enterprise7 and --userdir $HOME/.myproductuserdir to it.

The Native Product should have its own launcher called netbeans-native and read its own settings, specify its own user directory and list of clusters (probably --clusters /pathto/ide6:/pathto/web9 as the Native product is extension of the base NetBeans IDE without the enterprise part) and pass that information to the generic $nbplatform/lib/nbexec.

Configuring the Launcher

The behaviour of nbexec launcher can be influenced by special arguments and environment variables:
  • --clusters - specifies the paths to clusters that shall be placed on the execution stack (config, modules, configurations, etc.). Individual elements are separated using java.io.File.pathSeparator so for example on Windows it is ; and on Unix :

  • --branding - gives the name of branding that shall be used

  • regular parameters - these are end user oriented parameters printed when invoked with --help option: 
    Usage: bin/../platform4/lib/nbexec {options} arguments

General options:
  --help                show this help
  --jdkhome <path>      path to Java(TM) 2 SDK, Standard Edition
  -J<jvm_option>        pass <jvm_option> to JVM

  --cp:p <classpath>    prepend <classpath> to classpath
  --cp:a <classpath>    append <classpath> to classpath

Core options:
  --laf <LaF classname> use given LookAndFeel class instead of the default
  --fontsize <size>     set the base font size of the user interface, in points
  --locale <language[:country[:variant]]> use specified locale
  --userdir <path>      use specified directory to store user settings

Versioning of Clusters

 As clusters evolve on a different schedule, there comes a problem of compatibility. Easy solution is to version location of each version of a cluster. If the $nbplatform includes a revision in its name as for example /opt/netbeans/platform3 it is easy to release new incompatible version 4.0 and place it into /opt/netbeans/platform4. Other clusters then can depend on the right version of $nbplatform as there can be more than one installed. This has the advantage of avoiding incompatibilies, but has the disadvantage of locking you into a release that may not have improvements that a newer release might give (performance?). The improvements are important, the compatibility even more. The following paragraphs analyze and discuss the rules of compatible development and describe the solution that provides the right balance between compatibility and improvements adoption. If you are not interested in the discussion, just in the conclusion, you may jump right there.

Compatible development

Let's start with simple example. Imagine that there is Native Product 1.0 and Web Product 7.1 and that:
  • $nbnative cluster (in the Native Product 1.0) needs debugger major (incompatible) version 1 and minor x.y.z (as it does not matter for this example)
  • $nbweb (in the Web Product 7.1) needs debugger major version 2 and minor a.b.c
  • debugger module is provided by the base $nbjava, version 4.3 delivers the debugger major 1 (minor u.v.r where u.v.r >= x.y.z so it satisfies the requirements for Native Product 1.0) and version 5.1 provides debugger major 2 (and some specification version, which is not important)
A client wants to use both the Native and Web product at the same time. E.g. install both of them on the same computer, run them simultaneously (but not in the same VM) as two different applications. As one product needs debugger major version 1 and second major version 2, that means both versions have to be installed at once.

Requirement A: It is necessary to install more than one incompatible version at once.

Note: Version 3.1 of module A is incompatible with version 2.8 if there exists a module B that depends and runs with version 2.8 of A and does not run with version 3.1 of module A (more).

A possible solution is to encode the version (or at least major version) of the module in the JAR file. So instead of text.jar the module would be named debugger-1-1.32.jar. Then multiple versions could be installed at once. Another possible solution is to place the JAR files into different directories. Which means to encode some version number in the directories itself. Again this satisfies the requirement that multiple incompatible versions can be installed at once.

Packaging into RPMs

Let's now discuss how the module or set of modules will be packaged into native package formats. Let's imagine that:
  • An RPM package m.rpm contains some files and also debugger major version 1 and is delivered as part of the Native Product 1.0.
  • Another RPM package n.rpm (does not matter whether it is just a different version of m.rpm or has completely different name) contains the debugger major version 2 and is delivered as part of Web Product 7.1.
As we have the requirement A which asks for ability to install two versions of the debugger at once, we can easily deduce that both RPM packages have to be able to coexist at once. But to enable that there has to be no conflict between files contained in them.

Observation 1: Regardless of the size of native packages, an incompatible change in one module means that other parts of the package has to change location (pretend incompatible change) as well.

This implies that if we package whole cluster into one RPM and there is an incompatible change in one module, which happens nearly every release, all files in the RPM has to change location in order to allow coexistence with the RPM of previous release. Well, if we do this, then it is better to include the version number directly in the name of the directory, than uselessly mangle names of the modules.

RPM for Product and RPMs for Clusters

Imagine that we want to have the launcher for NetBeans IDE Product in a shared location (/usr/bin) and we want it to keep the same name when new releases are made (/usr/bin/netbeans).

Can this launcher script be part of the same RPM that contains the debugger module? Due to observation 1 it would have to change its name or location if debugger or other part of the RPM would change incompatibly.

That either means to include a version name in the launcher script (netbeans35) or keep it in separate RPM which only depends on other cluster RPMs.

Better seems to have own RPM for Product that just declares dependencies on RPMs for clusters, as this allows separation of compatibility versioning (nbjava35-1.0.rpm and nbjava36-1.0.rpm) that appear to the RPM management system as two different packages, the user visible versioning like NetBeansIDEProduct-3.5.rpm and NetBeansIDEProduct-3.6.rpm that will be treated as updates with proper notification. Of course this means to keep compatibility of the launcher script but that shall not be as hard nor too important.

Impact on Module System

As discussed in previous paragraphs it is possible and desirable to allow multiple (incompatible) versions of modules to be installed at once, but due to the nature of the system, these versions cannot be enabled at once in one runtime.

In some cases more than one version of the module could be enabled at once, but generally this is not possible. As many modules influence the content of system file system (via its layer) enabling two similar modules would very likely lead to unresovable clashes in their configuration resources. The module system would have to decide which of available versions enable and which not.

This is very similar to UNIX libraries. There can be more version of the same library available and different applications can link to the desired version. But no application can link to two versions of the library at once, as there would be conflicts in the symbol names, etc.

Observation 2:The module system then would need to be modified not to get confused by a presence of more similar modules at once and correctly enable the desired one.

Moreover it is not exactly clear which version enable and which not. The expectation of the Native Product 1.0 is to enable debugger major 1, as whole product is build around that version. The expectation of Web Product 7.1 are different. It needs debugger major 2. How the system is going to know that? By counting the number of dependencies on version 1 and 2 and enabling the version that satisfies more modules? This is a situation without a winning strategy.

As the compatibility is more important than any possible benefits from new incompatible updates, it is better not to do any tricks in module system and leave the decision on writers and packagers of the system.

External Contributions

Because of the modular nature of NetBeans system it is common that there exists a lot of extensions written as modules to the basic functionality of any product. There can be a module enhancing the refactoring functionality in Java sources contributed by external team which is not part of the base release of NetBeans IDE Project. There are two ways how such extension can be contributed and presented to user.
  • One can create own product. That means to start with new cluster $javaext, providing the search module and release own product NetBeans Extended IDE that will include $nbplatform, $nbjava, $nbxml and $javaext clusters. This way is suitable for major contributions, simple extensions will rather use a second way.

  • Snake into related cluster. As module extending java functionality is likely to be tight to java it can be added into the $nbjava directory. As such it immediatelly begins to be part of all products using the $nbjava.
Can such snaking into an cluster break products using that cluster? Not on linking or dependencies level, but there might be interferences on functionality level (another loader starts to recognize the same file, two editors registered for the same mime type, etc.). It is hard to guess the amount of such conflicts, it shall not be bigger than our current state when one can autoupdate - download modules and install them into products build on NetBeans. Anyway, there is a solution.

Every product defines its own private cluster not designed to be used by any other product and all extensions are sneaked into this one dedicated to all external contributions to the IDE (the cluster is named nb4.x in recent versions of NetBeans). Other products based on the $nbjava or $nbenterprise clusters do not see and cannot be affected by such extensions.

It is necessary to realize that sneaking a non-autoload module into a cluster that is designed for sharing is a bit dangerous. Every product will see such added module and the module will be enabled by default. This may mean changes in semantics, and that is why it is better (for non-autoload modules) to sneak into product private cluster.

There is another related problem to sneaking - uninstallation. If user installs external modules in the $nbjava dir created via package installation, then when uninstalling this cluster, this may create some problems. Uninstaller will not be able to properly clean up the product/cluster installation directories. Some files will be left behind. As the installer does not know if its safe to delete these dirs or not.

Restrictions

Althrough the system based on encoding a compatibility number of a version in a cluster location name works sufficiently fine, it still has to be used with a care as there is a problem that it does not solve: transitivity of incompatible change.

Example: Let's imagine that $nbide cluster version 4.8 is build on top of $nbplatform version 3.9. After a while new, incompatible release of platform is produced, placed into a separate directory and having a different number 3.10. When this is noticed by developers working on the $nbide product, they decide to rewrite their code to use the new version of $nbplatform, but they keep every own API backward compatible. Thus they release update to their product that has new version of $nbide cluster compatible with 4.8 (thus still in the same directory as previous version) and version 3.10 of $nbplatform. Now we can observe the compatibility transitivity problem.

Because if there is a product (like $nbweb) that was written against $nbplatform version 3.9 and $nbide version 4.8 and is using API interfaces from both clusters and relies on their compatibility, it can get broken when new version of IDE Product that depends on $nbplatform 3.10 is released. The reason is that $nbweb needs version 3.9 and the $nbide needs 3.10 and they cannot work together.

The transitivity problem is unwanted, uneliminatable effect. But it is easily preventable if developers are careful enough. The only necessary thing is to produce an incompatible version whenever any of clusters we depend on changes incompatibly. So in the example above, the IDE Product should include new incompatible $nbide 4.9 instead of pretending compatible evolution.

Conclusion

  • As not all clusters can commit to do compatible development for now and ever (reality of life)
  • As two or more versions of the module has to be installed at once (discussed here)
  • As RPMs carrying incompatible variations have to able to coexist (discussed here)
  • As having the two versions of a module would complicate the module system (discussed here)
  • As there shall be a Product and Cluster packages (discussed here)
  • As we need extensibility of clusters (discussed here)
One native package is created for each cluster (platform, java, xml, native, web) and places the cluster into a directory containing version specification (e.g. /opt/netbeans/platform-3.5). Note: It is possible to compose one cluster from multiple RPMs, as will happen in case of third party contributions, but that does not influence any of conclusions that follow. If a compatible update is released, it shares the same native package name and be placed into the same directory. Just the native package version is increased. On the other hand, new incompatible release has to be placed into its own directory (e.g. /opt/netbeans/platform-3.6) and must allow coexistence with the previous incompatible versions.

It is up to the individual clusters to decide whether they want to develop in compatible or incompatible way. Both is possible with all its pros and cons. The ability to deliver compatible releases highly depends on correct partitioning of clusters.

The cluster is packaged into one or more RPMs that are designed to keep external compatibility as much as possible - for that reason they contain the name of the version in their name (nbplatform5 vs. nbplatform6), thus allowing different incompatble versions of an cluster to be installed at once. It is possible that the same directory is filled with a content of foreign RPMs that just want to provide some extensions to the base functionality of such extension.

There is a product RPM containing just the launcher script and possibly private product cluster, having references to all clusters that it needs. This product RPM does not include compatibility identification as it will evolve in compatible way (also due to the fact that nobody is supposed to depend on it cluster) and thus new versions of the product are easily recognizable by native package managers and offered for update. Such update will then update all needed clusters with their appropriate versions. Removing of useless cluster native packages that are not needed anymore would be nice, but is more a task for the native packager that should realize that there is a package used by nobody.

Good Practices: Do not package things with different compatibility lifecycle together
In order to minimize the effect of incompatible change, it is better to keep the compatibility units in the right size. The lifecycle of Java Support is likely very independent from lifecycle of XML Support. If both of them are packaged in one cluster and thus share the same compatibility domain if one of them makes incompatible change, the other parts have to pretend incompatible change as well. This wastes and hurts people who depend on a feature in Java Support and have to make changes just because something incompatible happened in XML Support. That is why it is suggested to separate functionality with unrelated compatibility lifecycle into own clusters.
Good Practices: Separate API modules and GUI modules
API and GUI are example of interfaces that have exactly different compatibility lifecycle. While API has to be kept stable and compatible as much as possible, no such restriction is placed on GUI. Minor changes in each version are nearly requirement, incompatible changes common. That is why it is suggested to separate the modules providing API and those that provide GUI.

If separated, then the API module can become autoload and can be deprected after a while (but still offered for a compatiblity) and after another while completely removed. The GUI module can meanwhile change inside out, with a possiblity to introduce new API autoload module that replaces the old deprecated one.

Good Practices: API modules should not register anything
In order to implement the slow deprecation of an API and its replacement by a newer version it is necessary to prevent any clashes that could occur between the old and new module. An example of such clash are for example registrations in a layer or objects in a lookup. To prevent these problems it is suggested that API modules (which should be autoload anyway) do not register anything (or at least much) that could clash with their future replacements.
Good Practices: Do compatible development
Obviously evolving a module in compatible manner is the best way around all problems described here in. It is often better to replace an API with newer version while keeping the deprecated one around working well for clients that did not manage to migrate.

Breaking compatibility of a cluster every release means that products depending on your cluster will never get an updated version or in the best case, you will have to produce patches and updates for critical bugs to more incompatible versions of a cluster at once. Which is bigger price than one really wants to pay.

Real Layouts

 Here is the mapping of the logical layout to physical locations on different operating systems.
Windows
The simplest case is Windows. As it lacks any centralized package management at all, the physical and logical layouts will remain the same. Each cluster will be placed in its own directory ($nbcluster in c:\Program Files\NetBeans\platform3\) and the content of its directory will match the logical layout.

Appropriate execution scripts are supposed to be installed into the c:\Program Files\NetBeans\bin directory by the installer of actual Product.

Each product installer will mark and register each installed cluster into windows or JDK1.4 registry, so other installers are able to find the previously installed clusters and reuse them.

Solaris - workstation install
As all parts of NetBeans are unbundled (not part of Solaris OS distribution) the installation goes into /opt directory. Based on Unix Filesystem Hierarchy Standard, so for example $nbplatform will mainly be /opt/netbeans/platform3/ directory to identify the version).
  • The $nbcluster/config, $nbcluster/lib, $nbcluster/share and $nbcluster/docs are placed under /opt/netbeans/cluster6

The native package for each Product will provide launcher scripts and additional icons. Executables shall be installed in /opt/bin.

Solaris - compound install
There shall be a way how to install the cluster for evaluation purposes or as a shared server installation. In such kind of install the user shall have a way to specify the root $nbcluster directory and the physical layout will then exactly reflect the logical one as on Windows.

Example: One installs NetBeans into /server/for/clients/soft/netbeans/ on server and mounts it as /opt/netbeans on clients. The directory /opt/netbeans/platform-3.5 than contains everything config, lib, boot, modules, docs.

The default locations of other needed clusters in launcher script shall use relative paths, so if a set of clusters ($nbnative, $nbenterprise, $nbjava, $nbxml) is installed into one server location (/server/for/clients/soft/netbeans/) than there is a need of only one NFS mount to make all of them available on client systems. Moreover the relative paths will continue to be valid, whereever the components are relocated to. Of course these default paths shall be overridable by specifying arguments or some environment variables to allow usage of clusters in non-standard locations.

The native package for each Product that provides executables shall install them to bin directory under the NetBeans server installation directory. E. g. /server/for/clients/soft/netbeans/bin in the example in previous paragraph.

Note: For Solaris server-based installations, it is better not to edit the launch scripts at installation time. The path to $nbjava may be different on the desktops. Each desktop should mount $nbjava and $nbplatform to the default location, or each desktop should use an environment variable, or .... Also it is better not to complicate the installer by requiring different kinds of installations for servers. The installer shall not need to know if it is doing a server or a local install. No editing of scripts at install time.

Linux
The Linux case is the same as Solaris one, just instead of /opt we install into /usr/share for everything. In case of $nbplatform/lib/nbexec it should be in /usr/lib/netbeans/nbexec. Instead of /etc/opt we use directly /etc.

Linux Product RPMs will normally install additional things into e.g. /etc/X11/applnk/Applications, /usr/share/pixmaps, etc. Typically each Product (i.e. the RPM that included the product launcher script) would create a set of such files along to the command line launcher.

ZIP file structure
For purposes of evaluation and testing a ZIP file can be build every day for each product. Such archive would then contain all clusters necessary for the product under a common directory with the structure of each cluster exactly mirroring its logical one. The product launcher would be in a special bin directory. Here is an example of possible structure of NetBeans IDE Product: 
netbeans/bin/netbeans
netbeans/platform4/boot
netbeans/platform4/modules
netbeans/platform4/config
netbeans/ide7/modules
netbeans/ide7/lib
netbeans/ide7/config
etc.

User Directory Layout

 When running an application based on NetBeans usually a directory with write access is needed to hold temporary files, caches, log files, user modifications, etc. The logical as well as physical structure of such directory mimics the logical installation structure plus adds few directories where changes are being stored.
  • modules, docs: have the same meaning as in the common installation. The user can install additional modules here (usually by AutoUpdate because we do not want to mix the native packager installed modules with those installed by AutoUpdate).
  • config: contains user modifications to files found in shared config directories as well as those in module's layers
  • var/cache: contains pre-cached information about things that can be found elsewhere (mostly info about enabled modules, etc.)
  • var/log: directory to write logs to. Will contain more than one log file, at least messages, and older archives messages.1, messages.2 like the /var/log directory system does.
  • var/cache: directory to keep discardable caching files in. Right now used only by platform to cache informations about enabled modules.
  • There maybe additional directories provided by different clusters in the structure
It is not reasonable to share this directory between different Products - the cache would be useless, the logs would get confusing and also the user modifications to the config would could be ambiguous. That is why each Product shall define its own directory prefix (based on its name) and pass it into the general nbexec command (for example using the --defaultuserdir parameter). The user can override the default during invocation of the the product launcher (e.g. nbweb --userdir myuserdir).

Influence on other parts of the system

AutoUpdate

AutoUpdate has been modified to work with clusters on systems where it is used to update the whole product (Windows, ZIP installations on UNIX) and allow to install module not only as Global but also select the exact location where to install among the clusters used by the running product.

When a native package installation is used, AutoUpdate is restricted from accessing the directories/clusters under the control of native package manager. Which usually means to update just user directory.

Localization of updater must be possible. The proposed solution is to pass the branding and cluster directories from a product launcher directly to updater so it can in its early stages know the right language or branding variant.

Detailed Functional Analysis
  1. Regardless of how the product is installed, user is allowed to autoupdate to his user directory (if the autoupdate is present, e.g. it is not in webstart version). If that happens, the modules in user dir takes precedence over system one (if it is newer).
  2. If the product is installed from RPM or solaris package and possibly also from WindowsInstaller, the autoupdate is not able to update those clusters. This is signaled by existing $nbcluster/.noautoupdate file. In such case the autoupdate must not touch the directories.
  3. If the product or its part is not installed using native installation method (packages), the autoupdate is technically able to update these clusters. It will recognize them by non existance of $nbcluster/.noautoupdate (this is likely to be created by RPMs and other native packagers). In order to work correctly the AutoUpdate needs to decide which cluster the to be installed NBM belongs. If the NBM represents an update, it should be put into the same cluster where the original NBM was. If the NBM is new and user would like to install it globally, the module is installed into the "highest" - e.g. private cluster (in case of NetBeans nb4.x), as it represents the product private cluster and thus the influence of an NBM installed this way on other products is minimal - more likely zero.
Hotfix Example
The most desired use of AutoUpdate is for delivering hotfixes. So let's present a small example of how that could be done. Imagine we want to deliver new version of the editor module to our users.

First thing to do is to create an NBM file and make it available on one of our AutoUpdate centers. Users running on any platform, using any kind of installation method (but WebStart) can see it and without any restrictions install in their user directory. As the user directory takes precedence over shared install locations, the new editor module will be activated for those users. This is exactly as it works in version 3.6.

Users that used windows or ZIP installation style, will have a chance to select global installation of the NBM file and replace the editor module in ide4 cluster (as it was already installed).

Those that are using UNIX installation based on native packages will not be able to install NBM file globally, as it would clash with native RPM databases. Instead they will connect to their favourite RPM distribution server (urpmi, apt, yum - something like AutoUpdate for RPMs) and download and upgrade the native package that contains editor module. This requires those who are producing NBMs to also produce RPMs and Solaris packages or patches and make them available on suitable distribution channels.

Module System

There is the requirement 1 that components installed in separate native packages (javahelp, xalan, tomcat). In order to solve it we will need to use simlinks or enhance the module system to recognize not only files .jar, but also files .library that would contain full path to the set of JAR files that they reference. That way the clusters need not contain all their JAR files, but could reference other system components. This is tracked as issue 53898.
Comments to nbdev@netbeans.org please.