NBM cannot declare where cluster to install. NBM is installed in the userdir as
default. If NBM wants to be install globally then NBM is installed in same
cluster as a previous version (if any) or in the last cluster in common order.
NBM should have a attribute which says where to go in global installation.
- what to do if target cluster doesn't exists? New cluster will be created
- is this attribute mandatory? No
- is this attribute ignored if NBM is installed in the userdir (default)? Yes
- what to do if the target cluster is deferent then origin cluster of previous
version? Origin cluster has higher priority
- if a target cluster is not launched already then does Autoupdate make
launching it? No, it's NBM provider responsibility
A) A pack of NBMs makes a logical unit and could be useful to install it
together in a own cluster.
B) A new NBM should go near by functional friend.
Whatever change you make, please also update
Y01 Imho it should be easy and non controversal to select one of existing
clusters. Autoupdate just needs to know the list of clusters the launcher can
use. Either by using netbeans.dirs or some other property provided by the
Y02 It might be nice to have "logical names" for clusters, so one can say
"platform" and mean platform6, platform5, or use a wild card like "platform*".
Otherwise nobody is going to be able to create one NBM to work in multiple
Y03 Imho installing into other cluster that is not known by the launcher is
more complicated and possibly separate to the first problem. Imho this logic
cannot be in autoupdate, as it is supposed to know nothing about bin/netbeans
or etc/netbeans. This additional logic shall be somewhere in nbX.Y cluster -
my brainstorm would be to create an API in autoupdate and implement it in
ide/updatecenters which could be used by the autoupdate to ask for creation of
new cluster - the implementation could allow and modify the etc/netbeans - as
it is capable of knowing which launcher to modify and how. But as I said this
seems like independent problem to me.
Y02 may not be a very important feature; the workaround of preparing different
nbms for different releases is a fairly easy task, since the module jars
themselves won't change and an nbm is merely a wrapper around the jars. Still it
is a nice-to-have feature.
But Y03 is a critical feature. Since the product has been redesigned around
clusters, updates should also respect cluster structure. Since netbeans is
extensible and modular, nb should support creation of clusters for existing
netbeans installations and not force cluster creation only while installing a
new nb version.
Some info on the flags:
'global' - There is no reason in module system's view why to install NBM
globally (with only minor exceptions[*]). A module should behave correctly
whether installed globally or locally.
'restart' - this flag rarely used (restart=false is default[*]); Perhaps the
only reason to want to restart IDE is that a NBM changes something that an
another module reads in its module install.
[*] Exceptions are if a NBM wants to be installed into 'lib' or 'bin' directory.
Created attachment 29596 [details]
The task was implemented in main trunk. See attached commit.log.
Btw. more info at
Can you provide some info or example how I can specify the cluster in my build.xml when an NBM is
Forgot to ask if this change made it to NB 5.5 branch by any chance?
This is not in 5.5, 6.0 only.