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.
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. So, 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 UI spec. 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 non-obtrusive.
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 be disabled. 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 category.
@jglick 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?