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.
From http://www.netbeans.org/issues/show_bug.cgi?id=117390 : > Rename the right-click menu item to "Install into this IDE", the target IDE can also > be used for development so the wording is ambiguous. I think 'Install into this IDE' is a clearer text for the menu item (than the current text, 'Install/Reload into Development IDE'). In fact, if possible, it would be nice to do the following: - if target platform is same as this (current) ide, then display only one menu item 'Install/Reload' (which would be same as 'Install into this ide'). - if target platform is different from this (current) ide, then display two menu items: 'Install/Reload in this IDE' , 'Install/Reload into target IDE'.
Menu item rename is possible. Not sure if it is an improvement. No label changes considered for 6.0, anyway. It is impossible for the target platform to be the same as the current IDE because they could not be sharing a userdir, and the module is installed into a userdir.
> It is impossible for the target platform to be the same as the current IDE It is quite likely that i am not understanding the distinction between 'development' and 'target' platforms. When I install say NB6 and i do not have any other ide/platform installed, i can still develop modules and the target for the module projects is set to the 'current' ide automatically. I took it to mean that the 'target' platform is same as 'development' platform. But as you have explained, perhaps the distinction is not which nb install is used for running the module but rather which 'userdir' is used for installing the module. So, it seems that, in the case i have described, 'development platform' is (installed-ide + user-dir-in-installed-ide's-conf-file) and 'target platform' is 'installed-ide+a-different-userdir). As for the renaming, i did find the menu names confusing; but then i searched for 'install/reload' in javahelp and found that the help text was very helpful. (Though, I am still leaning toward 'Install into this IDE' being an improvement..). Hopefully the original submitter of issue 117390 would add comments/preference here. In the absence of any other feedback, please go ahead and close this as wontfix.
Right, userdir is more relevant. You can only run one instance of NB in a given userdir at a time (due to an exclusive lock file), but you could be running multiple instances from the same install dir. (This is why installing NBMs in the userdir is a bit safer than installing them in the general installation dir - there is no possibility of a race condition.) I will leave open for the menu item text which could probably stand to be revisited.
Thanks for the clarification. So, the following are the usecases: 1. Target is set to the same instance of NB that is used for the 'development' of the module. In this case, a. 'Target IDE' refers to running instance started with another testuserdir. b. 'development IDE' refers to running instance started with its netbeans.conf specified userdir. 2. Target is set to a different instance of NB tha the one that is used for module development. In this case, a. 'Target IDE' refers to target instance started with a testuserdir. b. 'development IDE' refers to target instance started with its netbeans.conf specified userdir. Hopefully, in 2b, a check is made to ensure target instance does not refer to the same userdir used by the development instance. (If not, should a bug be filed?)
Please ignore my previous post; the usecases are wrong. I will repost the entry with corrections.
No, "development IDE" refers to the IDE installation (binaries) and userdir which you are running to use the editor, etc. This is always an IDE. The target platform which you are building your module against (may be just the NB Platform, no IDE bits) plus testuserdir are referred to as "target". When you "Install/Reload in Development IDE" you are building your module, against whatever target platform, then loading it into the development IDE's user dir and running instance. This is generally only desirable for the occasional demo where you do not wish to start a target platform at all (e.g. you do not want >1 copy of NB running due to limited RAM). It is dangerous because if the developed module has some grave bug which interferes even with opening Tools > Plugin Manager, you may not be able to recover except by killing the process and manually deleting the module JAR. For normal development purposes you should always reload in the target platform, hence the warning dialog.
thanks again for the clarification. So, "development IDE" always refers to the (currently running) IDE installation and its current userdir. (Presumably this is true even if the current instance was started with a '-userdir <mydir>' option). The target IDE always refers to the target instance (which could be same as the current ide or a different ide/platform install) with a testuserdir. And all of this is meant only for development. For deployment, installing the nbm via the plugin manager, is the only recommended option.
Correct on all counts. I know the terminology is a bit confusing but that's what you get when you develop a tool which can be used to develop itself!
Oops, sorry, late to the table... Jesse is correct of course, "this IDE" would be just as ambiguous as it does not distinguish between "this userdir" or "this platform", the latter of which is the same for target and development IDEs. Moving this choice to a checkbox on a dialog would not be nice. I still think a rename is in order in the interest of usability. There is another usability problem that could be fixed--sometimes my mouse slips and clicks on I/R into this instead of target, they're right next to each other. How about an I-know-what-I'm-doing sub-menu called "Install/Reload into..." that would open another menu with "...this IDE's userdir" and "...the platform (affects all users)"? This would reduce the need for a warning, make it less likely to do the wrong thing by accident. As an aside, regarding reloading issues, it seems to me that reflection could be used to find out if any instances of classes from a module that is being reloaded are actually in use. What I'm thinking is some sort of deep-reload power-user tool that could be used to swap out any module. I'm not advocating that it be included in the standard distribution, but for platform developers it would be a godsend.