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.
Summary: | "Run Project" on context menu behaves differently from "Run Main Project" from the IDE menu. | ||
---|---|---|---|
Product: | apisupport | Reporter: | Jun Qian <jqian> |
Component: | Project | Assignee: | Jesse Glick <jglick> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jrojcek, ppisl, sanchofx1, tzezula |
Priority: | P3 | Keywords: | UI |
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Jun Qian
2006-08-31 22:37:38 UTC
How do you starting the netbeans module project from context menu? By "Install/Reload in Target Platform"? This action is the same as the main menu action. It's a ProjectSensitiveActions (ActionProvider.COMMAND_RUN,...) which calls the same project's ActionProvider. Or are you using the "Install/Reload in Development IDE"? Neither. I use the "Run Project" action that is above "Debug Project" action in the context menu. I just tried the "Install/Reload in Target Platform" action, it indeed gave me the same error as the "Run Main Project" from the main menu. OK, so it's misunderstanding on my part. I thought "Run Project" on the context menu is the same as "Run Main Project" from the main menu. My module specifies a different platform than the current NetBeans IDE. When I invoke "Run Project", which platform it is using? The current one, or the specified platform? If the specified platform, what's the difference between "Run Project" and "Install/Reload in Target Platform" then? The "Run Project" calls run target while the "Reload in the Target Platform" calls reload target. The reload passes the module to reload to the run.xml (<property name="run.args" value='--reload "${cluster}/${module.jar}"'/>). The run doesn't. Yes, currently Run Main Project is bound to reload. "Run Project" in the context menu does not invoke the reload command. I'm not sure which to make most prominent in the UI, really. "Run" is safest but "Reload" is much more convenient in case you are testing changes; the catch is that sometimes Reload does not work correctly and it is hard to say categorically when it will or will not work. Run can be misleading because if the target platform is already running, it has no effect (it just asks the platform to get focus, but any source code changes you have made will not be visible). You can already choose whichever action you prefer; the bug is the inconsistency in labelling, and possibly in a poor choice of default action. Run Project in the contextual menu should definitely perform the same action as Run Main Project. Whether it should be the "run" target or "reload" target is another issue. My understanding is that those targets perform differently when the target platform is already running. But I'm not sure what the difference is. Both actions build the selected module first. "Run" with the target platform not started starts it, with your changes loaded. With the target platform already started, it has no effect (except maybe fronting the window of the target platform); the old code is still in effect. "Run" is always safe to perform. "Reload" with the target platform not started is similar to "Run". With the target platform started, it reloads the selected module with your changes. "Reload" does not work on autoload or eager modules, for modules with many downstream dependencies it can be very slow, and in some cases not all changes will be correctly reloaded (depends on circumstances). First of all, I think "Run" should do something if the target platform is already running. I would expect it restarts the target platform and reloads my modified module. I clicked Run because I wanted to see the changes in action. Can it work like that? As for "Run" vs "Reload" mapped to "Run Project": We have a similar situation with web deployment. "Run Project" does incremental web app deployment which doesn't work 100% under certain circumstances. "Deploy Project" undeploys and then deploys web application which is slower but reliable. Adding Petr Pisl to Cc to confirm it works like that in web apps. If we do it like with web apps, we should map "Run Project" to "Reload", and have a separate action called "Restart Target Platform" or something like that. I guess module reloading works even less often than web app reloading - it is much harder to reload a module that has other modules depending on it, compared to web apps which are essentially independent. Re. shutting down and restarting the target platform - possible for new target platforms with changes in core to support a --exit CLI option, perhaps. Currently module developers who cannot use Reload are recommended to close the target app directly and then select Run, but of course it would be nice if this were automated. Okay then. Can we try to map the Run Main Project action to the "Run" target? This would make it consistent with Run Project contextual action. We'll see based on user feedback how it works out. I would like to add another point. I really got into trouble with this simple GUI issue. Starting a module suite app, by selecting the main menu's "Run" or the F6 key can cause problems even if the target platform is not running. The triggered "reload" action seems to reload the (main) module even if it is not neccessary (because the target platform was not running before). To me it looks like it is perfoming: compile -> run -> unload module -> load module Reloading causes class loader issues with ~50% of my modules. The problems caused by this behaivor are really subtile and extremely hard to debug becuase they depend on how you start the app (which you are not always aware of...). So effectivly I am currently avoiding to use the F6 shortcut. I think this issue can be solved by just providing clear action names. I would say it is perfectly OK for the user to learn that there is a difference between "run" and "reload". So users that want to "reload" should click reload, useres that want to simply "run" the app - click run. That's it?! To strengthen this concept one could eventually add a check to the "run" action code that refuses to proceed if the application lock is present and vice versa for the "reload" action (no reload without application lock). Just pop up an error message to the user and tell him how to use which action. I would like to point out that (at least for me) "reload" is a 'risky' action that should not be used 'by default' or without user knowledge behind the scenes. I would even suggest to have this fixed in the next release because it can create this kind of subtile errors in the user code. "I think "Run" should do something if the target platform is already running" - agreed, has been filed separately. Probably "Run" and "Debug" should always run "run" and "debug" targets, and there can be separate context menu actions for Reload in Target Platform and Reload in Development IDE for people who really want them. The former should probably also be enabled only if the target platform is currently running (otherwise just Run would work fine). Should be more consistent now. core-main #9f3a4c331ac5 Integrated into 'main-golden', available in NB_Trunk_Production #271 build Changeset: http://hg.netbeans.org/main/rev/9f3a4c331ac5 User: Jesse Glick <jglick@netbeans.org> Log: #83968: making Run/Debug/Reload in {Target Platform,Development IDE} more consistent. *** Issue 142495 has been marked as a duplicate of this issue. *** |