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.

Bug 83968 - "Run Project" on context menu behaves differently from "Run Main Project" from the IDE menu.
Summary: "Run Project" on context menu behaves differently from "Run Main Project" fro...
Status: RESOLVED FIXED
Alias: None
Product: apisupport
Classification: Unclassified
Component: Project (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords: UI
: 142495 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-08-31 22:37 UTC by Jun Qian
Modified: 2008-08-01 00:22 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jun Qian 2006-08-31 22:37:38 UTC 
This is for NetBeans IDE beta 2.

I am a NetBeans Enterprise Pack developer. I have a NetBeans module project
which is set as the main project in my NetBeans IDE. I tried invoking the "Run
Project" action from its context menu and invoking the "Run Main Project" action
from the IDE menu (or F6 shortcut). There is some subtle difference. I guess
it's the thread context class loader that is somehow handled differently. If I
press F6 to invoke the "Run Main Project" action, somewhere downstream I get the
following exception:

Thread AWT-EventQueue-1: The 0th supplied input is not a schema document: its
type is N=
org.apache.xmlbeans.XmlException: Thread AWT-EventQueue-1: The 0th supplied
input is not a schema document: its type is N=
        at
org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:211)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.apache.xmlbeans.XmlBeans.loadXsd(XmlBeans.java:496)
        at
org.netbeans.modules.compapp.test.wsdl.WsdlSupport.loadSchemaTypes(WsdlSupport.java:148)
        at
org.netbeans.modules.compapp.test.wsdl.WsdlSupport.loadSchemaTypes(WsdlSupport.java:123)

This is always reproducible.

On the other hand, if I run the project through the "Run Project" context menu,
I never have this problem. 


A google search for the above exception reveals this useful link:
http://www.mail-archive.com/dev@xmlbeans.apache.org/msg00300.html
Comment 1 Tomas Zezula 2006-09-01 07:13:42 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"?
Comment 2 Jun Qian 2006-09-01 07:29:01 UTC 
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?
Comment 3 Tomas Zezula 2006-09-01 10:41:30 UTC 
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.
Comment 4 Jesse Glick 2006-09-01 17:06:29 UTC 
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.
Comment 5 jrojcek 2006-10-09 16:00:14 UTC 
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.
Comment 6 Jesse Glick 2006-10-10 16:28:22 UTC 
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).
Comment 7 jrojcek 2006-10-12 16:01:43 UTC 
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.
Comment 8 Jesse Glick 2006-10-12 16:53:57 UTC 
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.
Comment 9 jrojcek 2006-10-13 08:51:30 UTC 
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.
Comment 10 sanchofx1 2006-12-23 11:42:25 UTC 
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.
Comment 11 Jesse Glick 2008-06-19 23:32:24 UTC 
"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).
Comment 12 Jesse Glick 2008-06-20 01:44:24 UTC 
Should be more consistent now. core-main #9f3a4c331ac5
Comment 13 Quality Engineering 2008-06-20 15:56:07 UTC 
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.
Comment 14 Jesse Glick 2008-08-01 00:22:46 UTC 
*** Issue 142495 has been marked as a duplicate of this issue. ***