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.
In adding the javacard1 cluster to the build, I spent 3 hours debugging why my cluster was not being built, only to discover the problem was my cluster was missing from ide/launcher/netbeans.clusters I can't think of any reason we need a hardcoded list here - the build can figure it out itself and generate the file. If it's only so that "ergonomics" is ordered correctly, that's not a good enough reason - easy enough to do in the build.
Rather than doing it in the build, the IDE's launcher should just autodetect any clusters in the installation, IMHO.
Keep in mind that there could be also absolute path specified for clusters in netbeans.clusters. Also I think there should be a way to disable cluster (other than deleting it).
Could still be done sanely. Auto-detect clusters by default. If "someCluster" is present, but netbeans.clusters contains #someCluster then disable it. If netbeans.clusters contains /path/to/some/cluster and it's not under $NB_INSTALL, install it. (while we're at it, I'd suggest ignoring the cluster numbers - i.e. #profiler means no profiler, even if the cluster is called "profiler3")
I do not think this would be very intuitive. If someone does not want some cluster (which is autodetected) he will check netbeans.clusters where he finds there is no entry for it. Almost no one will find out that to disable cluster he has to add it to netbeans.clusters and comment it. Pretty strange. If someone would try to disable cluster which has entry in netbeans.clusters by deleting the entry, he would be confused as well - the cluster entry would be deleted but autodetect would enable it anyway. I can imagine that autodetect could be enabled if netbeans.clusters is deleted (no netbeans.clusters->autodetect, netbeans.clusters present->current behavior). But still it would be hard for someone to guess that he can enable/disable autodetection by deleting/creating file.
What end user needs to enable or disable cluster present in the installation by editing netbeans.clusters? This is a nonexistent use case as far as I am aware. If you want to disable or remove some functionality, you use Plugin Manager. If you are developing a _product_ which has special needs for picking up clusters from various locations, you should be using a custom launcher anyway. We are talking about the NB IDE launcher. So I still recommend simply deleting netbeans.clusters and always autodetecting clusters. But if you insist on having this functionality be available for some specialized use case, then read netbeans.clusters if it exists and autodetect clusters otherwise. The standard NB IDE download (ZIP or installer) would never include a netbeans.clusters file, but some exotic packaging modes might use one.
> What end user needs to enable or disable cluster present in the installation by editing netbeans.clusters? > This is a nonexistent use case as far as I am aware. If you want to disable or remove some functionality, you use Plugin Manager. E.g. testing whether certain issue exists if ergonomics is disabled was quite common use case in past few months. I do not see how to disable it in Plugin Manager. But OK, I will use autodetection if clusters file is missing and keep current behavior if netbeans.clusters exists.
mv ergonomics /tmp ./bin/netbeans mv /tmp/ergonomics .
Perhaps -profiler3 would be more intuitive than #profiler3 At least similar to syntax we use in other places (not that an end user will know it)
If we adopt the policy of reading netbeans.clusters if it exists, else using autodetection, then there is no need for a subtractive syntax.
I find out that there is necessary to have list of clusters. Autoupdate needs to know cluster names (which may not yet have corresponding directories) to work correctly.
I don't see why that is a blocker. Autoupdate needs a list of clusters. There's no reason that must be a file on disk - the IDE is running, it knows what clusters it has when it is running. If it's a question of the updater, that could easily be passed a pointer to a temporarily created list if necessary; if necessary elsewhere, there could be an API to get the list. There's no reason autoupdate *requires* that $NB_HOME/etc/netbeans.clusters exist - it just happens to be written that way now - and can be changed.
The point is that AU currently needs also cluster names of non-installed clusters to correctly install modules from these clusters. Launcher can find which clusters are currently installed, but it cannot guess names of all existing clusters (which is now supposed to pass to IDE). If you wish you can file issues against AU and I will change launchers once the full cluster list is not needed.
What is the reason for passing clusters from launchers anyway? Why IDE does not read netbeans.clusters itself?
Can you be more specific about "Autoupdate needs to know cluster names"? NBMs which specify a cluster should be unpacked into the corresponding subdir of the NB installation directory, whether it already exists or not. NBMs which do not specify a cluster (i.e. built under "extra") get unpacked into the userdir. "Why IDE does not read netbeans.clusters itself?" - nbexec needs to know the list of clusters anyway, so it passes these in to the runtime as netbeans.dirs.
I was told that if AU installs module from cluster which was not passed from launcher it will be installed to userdir instead to proper cluster dir. I also remember that when I rewrote win launcher I was passing only existing clusters and I was asked by Jarda to pass all (9ae12cd74863). Jarda may comment more why it is required and what has to be changed.
Re. "Jesse's install dir" - there is no such thing like an install dir from point of view of AU and Module System. Just list of existing or potential clusters. All I want to point out is that the change is not going to be just in launcher. It will be wide span. And it deserves standard API review (not talking about executive sponsor, being included in the plan, buy-in by almost all NetBeans teams, appropriate QA resources, etc.).
All AU needs to do when encountering an NBM specifying a cluster name which does not correspond to any current entry in ${netbeans.dirs} is this: rather than using ${netbeans.user} as now, create the directory as ${netbeans.home}/../${cluster}, assuming ${netbeans.home} is a dir named /platform\d+/ in the usual style and ${netbeans.home}/.. is writable.
for that matter, why not allow named clusters in the userdir, for those users w/o write access to their install of NB?
We don't need named clusters in the userdir, I think. Anyway that would be a separate issue, don't confuse this one.
I have no plan to implement this anytime soon.
Should still be fixed. Current hardcoded list in ide/launcher/netbeans.clusters is nonmodular.