Bugzilla – Full Text Bug Listing
| Summary: | Error when running tests with missing plugins does not provide enough info | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Nick Edgar <n.a.edgar> |
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse, markus.kell.r, wassim.melhem |
| Version: | 3.0 | ||
| Target Milestone: | 3.2 M3 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Nick Edgar
Note: I sometimes run tests in this way in order to test against the build rather than the code loaded from CVS. Adding org.eclipse.test.performance to the set of plugins fixed up the problem. At startup, all we (the test runner) know is that the plugin containing the tests is not found in the registry. We can't provide any analysis, so all we can do here is improve the message to tell you that "the plugin containing the tests is either misssing or has been disabled due to a missing dependency." Incidentally, I hope you used the "Validate Plug-in Set" button on the Plugins tab of the launcher to figure out that org.eclipse.test.performance was missing ;-) Should this be moved to runtime, then? I was just wondering if there was somewhere else I should look for a log file. The Validate button is nice. But since the set of plugins in a launch config can change by adding/removing projects from the workspace, would it not be better to check when launching? Upon re-reading your report, I am surprised that you did not find anything in the log. I think, once upon a time, disabled plug-ins used to be reported in the log. In any event, I will improve the message on the PDE side, but this is really a runtime issue, since by the time the PDE/JUnit applications gets invoked, the registry had been built. >But since the set of plugins in a launch configcan change by adding/removing
>projects from the workspace, would it not be better to check when launching?
The button will just give you a preview of any imminent disaster. It is a
relatively costly operation and thus is only done on demand.
If we were to do a gratuitous check at the time of the launch, it will be
duplicating what the runtime is doing.
As long as the log is visible ;-). We only check and log unresolved plug-ins if in debug mode (see bug 62118). And since the instance location does not get set (we fail too early), the log would be in the configuration area (inside org.eclipse.pde.core's state location). I was running it under the debugger, and did not see anything in the PDE core metadata area either. Sorry, I meant running with -debug or tracing enabled (and this is an exclusive or). OK, I added -debug to the command line. The log now (in the workspace dir, not the PDE metadata area) has: !SESSION Sep 23, 2004 14:58:26.866 --------------------------------------------- eclipse.buildId=unknown java.fullversion=J2RE 1.4.2 IBM Windows 32 build cn142-20040917 (JIT disabled) BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -version 3 -application org.eclipse.pde.junit.runtime.uitestapplication -pdelaunch -port 3337 -testpluginname org.eclipse.ui.tests -classnames org.eclipse.ui.tests.multipageeditor.MultiPageEditorTestSuite !ENTRY org.eclipse.osgi Sep 23, 2004 14:58:26.876 !MESSAGE Bundle update@/d:/eclipse-new/plugins/org.eclipse.ui.tests/ [88] was not resolved. !SUBENTRY 1 org.eclipse.osgi Sep 23, 2004 14:58:26.876 !MESSAGE Missing required bundle org.eclipse.test.performance_0.0.0. So this is more helpful. However, I thought PDE tried to tell the user about any log file created. It didn't in this case. Or is that only if there's a certain exit code? If so, then it looks like uitestapplication is not returning the right error code. The PDE launcher listener prompts you to see the log (if available) when the exit code of the launch is abnormal. uitestapplication is certainly guilty of not returning an appropriate exit code, but even if it did, the runtime, as I just read, does not log unsatisfied dependencies unless in -debug mode, so the log file would not be there in normal circumstances, and PDE could not let you know anything. That means you are going to move this bug to your bucket and change the applications provided by PDE Junit to return a non-zero exit code when no tests are run? <g> I'll move to my bucket, but I don't know how Nick would be better off in any way, if he doesn't use -debug and hence no log would be found. Maybe your error message could suggest running with -debug <g>. With what I know now, your idea from comment 3 to do automatic validation upon launching (as an option perhaps) is starting to look a lot more attractive now. Regardless you add validation to the launch configuration UI, I think that instead of just returning an arbitrary exit code, org.eclipse.pde.junit.runtime should throw an exception to the caller (instead of writing to the console. Then Core could take care of logging any unresolved bundles (if it has not done that yet) in case that happens. *** Bug 75648 has been marked as a duplicate of this bug. *** Rafael, although it's along the same theme, I don't think bug 75618 is a duplicate of this bug, since whatever I do here will not help Markus. The problem is that the runtime does not log error messages as to why plugins are disabled unless you pass the -debug flag. Errors of such nature are serious enough to be logged by the runtime whether or not you're not in debug mode; otherwise, the user (includig this seasoned Swiss user) is left puzzled as to why his plugins are not showing up. In his case, the runtime Eclipse came up (i.e. the launch did not abort with some error code). He is therefore left wondering why oh why his plugin did not show up. I therefore suggest the runtime team reexamine their position on when to log unsatisfied dependencies. I would have to agree. Judging by posts in the eclipse.platform.rcp newsgroup, almost everybody hits this problem when first trying to deploy their RCP app (they generally have less problems when running from PDE). While Wassimm's much-anticipated RCP app deployment wizard will help with this (not to mention the Validate Plugins button in the PDE launcher), it would be nice if runtime was more self-explanatory when something went wrong. If the cost of doing the dependency analysis is expensive, would it be possible to just set a flag if any plug-ins get disabled due to unresolved prerequisites, and then only do the full dump if the flag is set? I reopened bug 75618. Wassim, when I launch an Eclipse Application, I am getting any problems with dependencies dumped to the log even though I don't have -debug on the command line. For example, if I uncheck org.eclipse.jface from the browser example's launch config, I get: !SESSION Oct 05, 2004 14:12:49.527 --------------------------------------------- eclipse.buildId=unknown java.fullversion=J2RE 1.4.2 IBM J9 2.2 Windows 2000 x86-32 j9n142-20040917 (JIT enabled) J9VM - 20040916_0908_lHdSMR JIT - r7_level20040915_1801 BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -product org.eclipse.ui.examples.rcp.browser.product -pdelaunch -url d:\web\eclipsecon home.htm !ENTRY org.eclipse.core.runtime Oct 05, 2004 14:12:49.537 !MESSAGE Product org.eclipse.ui.examples.rcp.browser.product could not be found. !ENTRY org.eclipse.osgi Oct 05, 2004 14:12:49.557 !MESSAGE Application error !STACK 1 java.lang.RuntimeException: No application id has been found. at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:313) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:273) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) at java.lang.reflect.Method.invoke(Method.java:391) at org.eclipse.core.launcher.Main.basicRun(Main.java:185) at org.eclipse.core.launcher.Main.run(Main.java:704) at org.eclipse.core.launcher.Main.main(Main.java:688) !ENTRY org.eclipse.osgi Oct 05, 2004 14:12:49.567 !MESSAGE Bundle initial@reference:file:d:/eclipse-new/plugins/org.eclipse.ui/ [6] was not resolved. !SUBENTRY 1 org.eclipse.osgi Oct 05, 2004 14:12:49.567 !MESSAGE Missing required bundle org.eclipse.jface_0.0.0. !SUBENTRY 1 org.eclipse.osgi Oct 05, 2004 14:12:49.567 !MESSAGE Missing required bundle org.eclipse.ui.workbench_0.0.0. !ENTRY org.eclipse.osgi Oct 05, 2004 14:12:49.577 !MESSAGE Bundle initial@reference:file:d:/eclipse-new/plugins/org.eclipse.ui.examples.rcp.browser/ [7] was not resolved. !SUBENTRY 1 org.eclipse.osgi Oct 05, 2004 14:12:49.597 !MESSAGE Missing required bundle org.eclipse.ui_0.0.0. !ENTRY org.eclipse.osgi Oct 05, 2004 14:12:49.597 !MESSAGE Bundle initial@reference:file:d:/eclipse-new/plugins/org.eclipse.ui.workbench/ [8] was not resolved. !SUBENTRY 1 org.eclipse.osgi Oct 05, 2004 14:12:49.597 !MESSAGE Missing required bundle org.eclipse.jface_0.0.0. How is this happening? Does -pdelaunch imply -debug? Interesting. You have to ask the runtime guys about that. -pdelaunch is unrelated though. the -pdelaunch arg is an internal arg only used by PDE to distinguish between a dev app and a runtime app. It affects the way we read the target platform. Rafael, can you comment on comment #22? Are you sure you haven't enabled tracing in the launch configuration? Yes. Tracing is not on. Ok, this goes back to the point I made before (comment 17). If something really bad happens (the application cannot start, or exits with an exception), we log any unresolved bundles (bug 63858). OK, thanks, that explains it. I actually get the same behaviour when running a deployed example (not via PDE). >I actually get the same behaviour when running adeployed example (not via
>PDE).
Mission accomplished for PDE :-)
PDE now gives you the option (a checkbox) on the Plugins tab of the launch config to do an automatic plugin dependency analysis prior to launching. |