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 : > 4. When "Install/Reload into Development IDE" is selected from > the right-click menu and the warning window pops up, add a > checkbox to the warning window to allow installation into > the platform as opposed to userdir. I notice that a closely related issue was discussed at http://www.netbeans.org/issues/show_bug.cgi?id=76829 and 'global' install checkbox was deliberately removed after discussion. Is adding a checkbox as requested above same as (and will result in) setting the 'global' flag in the nbm? If so, is the suggested workaround to manually install the nbm globally? Or can the checkbox be added (if it makes sense) and the module installed globally by the apisupport module, without introducing the 'global' flag in the nbm itself?
Using I/R into Development IDE is dangerous and obscure enough as it is; and installing NBMs into the install dir rather than user dir is also relatively unusual. There is no particular reason to mix the two. If you really wanted to you could build the .nbm file and then use Plugin Manager to install it however you like.
I agree with the evaluation. (It really doesn't buy much to install an nbm being developed into the install dir. It makes sense to do the final deployment using the plugin manager).
Actually, we install modules into the platform all the time, having to go through the plugin manager every time is an unnecessary pain. We're developing on the NB platform a large application framework (see http://neurospy.org) that is growing more and more complex. We have 20+ modules in several suites four layers deep. It is a very common use case that we have to develop a module in the middle of the hierarchy while running a higher-level module. For instance, imagine we have a "scanner" module and a "digitizer" module. These are completely independent hardware subsystems, so the respective modules belong in their separate suites with their separate APIs and so on. It is possible to do limited development and testing of the "scanner" module without the higher levels of the module hierarchy, but eventually we have to run a scanner together with a digitizer and drive everything from the higher-level module to get a meaningful microscope. NB platform doesn't permit depending on modules outside the suite that are installed in the userdir, so we have to install into the platform. What we do, then, to speed things up is install an old version of the mid-hierarchy module together with the high-level module into the platform, and set main project to the mid-hierarchy module. Then "I/R into Target" replaces the platform version of the mid-hierarchy module with the one we're developing, so we don't have to rebuild everything on every iteration nor keep all modules in a single suite. This is a problem similar to "platform chaining" that Fabrizio discussed here: http://www.tidalwave.it/infoglueDeliverLive/ViewPage.action?siteNodeId=270&languageId=1&contentId=1655 (see also http://www.nabble.com/Chainig-Suites,-the-foreign-way-t4492247.html)
You do not want to use "Install/Reload..." for the described purpose. Simply write an Ant target which unpacks an NBM to the desired platform; or copies an entire cluster from a build area onto some platform; etc. Such a target can be inserted into the dependency list of some other script so that everything is automated. In the unlikely event that you _did_ want to actually reload a module into the installation dir of an app which was running at the time, just write an Ant target to 1. Copy the module into the right location, by whatever means (as above). 2. Run the target platform with the correct --userdir parameter and pass also "--reload /path/to/module.jar".
Frankly, I do not understand your resistance to making it easy to replace running modules in the running platform. I understand the target platform concept well and it is not a full solution to the problem described for two reasons: 1. Every developer on every project in the future who runs into this problem has to understand how to make an Ant target to do this. Then they have to understand how to stick an action into the right-click menu to make this easy. These are unnecessary expectations that, in the end, reduce the value of the IDE to the world. I grew up with 'make' and never bothered to learn Ant. The reason I'm using this IDE is that it hides oodles of these commonly encountered complexities and lets me be productive. 2. Reloading the .jar in the running target platform doesn't make a new module appear in the list of possible dependencies in the module suite properties window (as of 5.5.1, didn't check in 6.0). I still have to exit and restart the development IDE for the change to take effect. I understand that reloading running modules is not safe, and I'm not asking for it to be as long as it works most of the time (it does) and saves me a few hours a week. There *are* many situations where it's far more productive to have every developer keep their own "dangerously dirty" copy of the platform and deploy in place instead of on a separate target. Believe it or not, I'm limited by circumstances beyond my control to hardware with a fixed and relatively small amount of memory; having two platforms running at the same time makes the system thrash, while it runs smoothly with only one platform open.
Regarding #1, only the most common and obvious actions are prepared as choices for the GUI. For corner cases, especially on large complex projects or those with special requirements, you need to do some customization such as adding Ant targets. Or in this case, you can add modules "by hand" using the Plugin Manager. #2 is a bug if true - file separately. I can't promise when it would be fixed as it would not be a high priority. You can add module dependencies directly to project.xml in any case - there is no strict need for the GUI dialog. Suite chaining in general is only marginally supported. An entirely different organization for module projects would probably be preferable, but as there is no one working on apisupport except for a handful of bug fixes this is not likely to change in the near future.
I tried following your advice and adding an ant target to deploy globally into the target platform, but am unsure where to start. Could you provide an example so that I may put it into the wiki? In brief, suppose I create two standalone modules, module1 and module2, and declare that their target platform is one I copied from the NB distribution and added through the platform manager. 1. What would an ant target look like to deploy both these modules globally into the target platform into a cluster of my choice? The ant target should run only one instance of the target platform when executed on both the modules in sequence (same userdir), and the first deployed module should appear in the list of possible dependencies for the second module after the ant target is executed on it. 2. What's the best way to override F5 and F6 to perform such global cross-deployment by default for all the modules and suites that comprise the greater application?
See issue #125522 for unsupported hints.