This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
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. Questions: - 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 Use-cases: 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 http://platform.netbeans.org/articles/installation.html#influence-on-autoupdate 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 launcher. 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 versions. 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] commit log
The task was implemented in main trunk. See attached commit.log.
Btw. more info at http://platform.netbeans.org/articles/update-descriptor-specification.html#what-is-target-cluster
Can you provide some info or example how I can specify the cluster in my build.xml when an NBM is created? Thanks.
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.