Product Version: NetBeans IDE Dev (Build 20071009102105)
Java: 1.6.0_01; Java HotSpot(TM) Client VM 1.6.0_01-b06
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)
In the Plugins window, Updates tab, two of the listed plugins specify "deadlock" as Source. This is the name I gave to
the UC at deadlock.netbeans.org. The updates are named "Java EE Server Registry" and "Web APIs". Now, I suspect that the
plugins are actually installed in the NB install directory and not in the user dir. Looking at the Source property of
the same plugins in the Installed tab seems to confirm this: both say "Source: NetBeans IDE Dev (Build 20071009102105)".
So what's going on? Are these updates going to be installed in the base NB directory or into user dir? I can't find any
indication of this. In this case, I *don't* want them installed in the user dir.
1. The Plugin Manager should tell me, which plugins listed as updates are currently installed into the user dir and
which are in the base dir. This is an important information - I never install such plugins into user dir to avoid
awkward situations after updating the base IDE (this happened to me more than once).
2. PM should tell me, where is it going to install the plugins - user dir or shared dir.
3. There should be a way to hide the plugins that I don't want to install. I don't want to uncheck them every time I'm
updating some other plugins - this is irritating and error-prone.
4. I want to be able to explicitly specify, where I want to install the plugin. (p.3 in issue #117390)
> This is an important information - I never install such plugins into user dir to avoid awkward situations after
updating the base IDE (this happened to me more than once).
Well.. actually, sometimes I do this - when the plugin that I received with the base IDE is broken and I know that the
module in the UC fixes it. So what I really want is a choice - install this module in the user-dir, in the base dir or
hide it. I'd expect user dir to be the default destination for modules that are already installed there, and base dir -
for the modules that are installed there.
The original purpose for Plugin Manager redesign was to simplify intentionally its use. This purpose was reflected in
Naturally there are many information that might be welcomed by advanced users. UI spec. might be reevaluated in the
future according to the feedback.
You didn't mention, what am I supposed to do in such case. I, as a user, know that the IDE is going to do something with
disruptive potential, but I'm not sure, whether this will really happen, as the IDE won't let me know. For me it's a
stop sign - I don't install these updates, and they begin cluttering the updates list. Maybe not such a big deal, but I
wonder, whether something like this is going to happen in the production version.
I don't understand this issue. Closed as worksforme.
What is unclear?
I'm sorry. It's clean now.
Quoted from issue 101069:
>> On a related note, I would really like to be able to specify for a given wizard run whether modules should be placed in
>> the installation directory or user directory. Currently NBMs with a defined cluster are unconditionally placed in the
>> installation directory, which is a pain if you keep a single userdir but routinely replace your installation with a new
>> dev build.
> Well. It's meaningful use-case. It's currently tracked as issue 118234.
Regarding p.3 in the issue (hiding specific updates): I like the way it is done in Windows Update. Convenient and
Ideally I would like for PM to offer a radio button group (?) before installing plugins asking where they should be
installed - installation vs. userdir.
1. If the plugin is already installed, the radio button for the existing location would be selected, and the group would
2. Else, if the plugin specifies a cluster name, the radio button for "installation" would be selected but you could
switch it to "user directory".
3. Else the radio button for "user directory" would be selected but you could switch it to "installation".
The complication is that this distinction would in some cases need to be made for each module being updated, including
invisible modules, and I am not sure what you would show in case the modules to be installed fell into more than one
re 1: two questions:
a) why not allow installing the update into the alternative location? i.e., if the plugin is currently in the install
dir, remove it from there and install the update into the user dir and vice versa.
b) why not allow having the plugin in both install dir and user dir? (AFAICT, that's how it currently works, when the
plugin is installed in the base dir and the plugin specifies a cluster in the user dir?)
I can see use cases for both options.
Generally, the solution that would work for me the best would be a radio button group:
- keep current location for existing modules and use default location for new ones
- install all into the user dir
- install all into the base dir
- choose location per module (advanced)
If the fourth option is chosen, a table listing all the updates is shown with the following columns:
Name | New version | Base dir version | User dir version
The idea is to make the cells in the two last columns kind of toggle widgets - clicking them selects to install this
module into the corresponding directory, clicking again reverses the selection. When a cell is selected for update, its
text becomes bold, deselected cell is in normal text. When the table is first shown, select the cells according to
default locations as you mentioned. I think since this table is for advanced users it would be safe to include hidden
modules in the list. Of course, before allowing the user to perform update, the wizard will have to make sure that all
the dependencies are satisfied (i.e. installed into either user dir or base dir, or both).
For the sake of completeness, I would allow access to a similar table outside the context of updates: it can also be
used to uninstall modules from their current locations, as well as duplicate or move modules from one directory to
another. I don't think there is much danger that a novice user would occasionally do something horrible with such a
tool. The worst case is that removing the user dir or replacing the base dir some modules will end up with unsatisfied
dependencies. In this case, btw, it should be easy enough for the IDE to offer fill the dependencies using PM and then
search for them in the installed UCs. The absolutely worst case is if the UCs that a certain dependency came from are no
longer in the UC list. Not a big problem, methinks: if the user added this UC once, he can do it again.
P.S. Since the discussion is already broad enough, let stress a related point.
I'd like to have ability to downgrade specific module to arbitrary version, as long as it's present in one of the UCs
and downgrading doesn't break dependencies. This would be very convenient, when the current version is broken. The only
current way to downgrade a broken module is to uninstall it. Now, if there are many modules that depend directly or
indirectly on this module, downgrading becomes a nightmare: the IDE forces you to uninstall them all, then install the
older version of the guilty module and then reinstall all the modules that depended on it.
> I'd like to have ability to downgrade specific module to arbitrary version, as long as it's present in one of the UCs
Also allow downgrading to a manually downloaded nbm.
"if the plugin is currently in the install dir, remove it from there and install the update into the user dir and vice
versa" - perhaps, but this seems more dangerous.
"why not allow having the plugin in both install dir and user dir?" - because then it is unclear to the user which is
actually being used.
"that's how it currently works, when the plugin is installed in the base dir and the plugin specifies a cluster in the
user dir" - no, clusters are specified by simple name only. Currently if an NBM specifies a cluster name, it will always
be put in the installation dir under that cluster (creating a new cluster if necessary).
Downgrading is I think mentioned in another issue. It is unrelated.
>> why not allow having the plugin in both install dir and user dir?
> because then it is unclear to the user which is actually being used
Agreed. So let's show which directory is being used (and allow choosing it). But this becomes a bit too complex. Perhaps
the usual policy of "user config always overrides" would work the best? Simple, everyone is used to it, and it would
still allow you to install a new plugin version just for testing and be able to roll back to the system default afterwards.
Jesse, what if use 3-state combo box with possible states:
* Follow plugin metadata
* Install into install dir
* Install into userdir.
This combo will be placed both in Setting tab (for default value) and in Install wizard too. If the case install dir is
not writable, then Install into will be selected only.
I fear no one will know what "Follow plugin metadata" is supposed to mean. Anyway it would not be obvious that this
applies only to new modules, not upgrades (since upgrades have to be put in the same place as the original).
Reassigning to the new "autoupdate/*" owner dlipin.
I don't see much value to spend time on this. Anyone wants to provide a patch in addition to previous advices?