Community
Participate
Working Groups
in RC1 - start with an empoty workspace - target the RCP SDK - go through the new Plugin wizard and make an RCP Hellow world plugin called Test (I unchecked the creation of a Plugin class but don't think that matters) - when the plugin is created, launch it from the Overview page in the plugin editor - it runs fine - open the launch configuration and look at the list of plugins selected - notice that update.configurator is not checked even though it is in the target. - bummer. It should be. - ok, check it off and launch again - the launch fails as the Test plugin could not be installed and thus the application is not found. The log contains !ENTRY org.eclipse.update.configurator 2005-05-29 12:39:25.636 !MESSAGE Could not install bundle ../../book/workspace/test/ c:\target\eclipse\..\..\book\workspace\test !ENTRY org.eclipse.osgi 2005-05-29 12:39:25.767 !MESSAGE Application error !STACK 1 java.lang.RuntimeException: Application "test.application" could not be found in the registry. The applications available are: <NONE>. at org.eclipse.core.internal.runtime.PlatformActivator$1.run (PlatformActivator.java:216) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:375) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:162) 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:324) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334) at org.eclipse.core.launcher.Main.basicRun(Main.java:278) at org.eclipse.core.launcher.Main.run(Main.java:973) at org.eclipse.core.launcher.Main.main(Main.java:948)
This definitely has to be resolved for RC2. Taking the liberty of upping the priority.
>notice that update.configurator is not checked even though it is in the >target. >- bummer. It should be. Not really. People have always requested for PDE to launch with the minimal set of plugins required to launch their application. In this case, update.configurator is not on the required list of your plugin. Therefore, it would be "gratuitous" to add it. So this will stay as-is. As for the error you got after adding update to the list, I will investigate, but we have seen cases before where PDE is generating the right files but the runtime is unhappy when the same launch config switches from non-update to update (and vice versa), but I thought Tom already fixed that.
I was able to reproduce the error. I verified that the config.ini generated by PDE has the correct content referencing runtime@2 and update.configurator@3 on the ill-fated launch. So this is either Runtime or Update. Since we have seen a similar issue with Runtime before, I will arbitrarily move to that component.
Tom/Pascal, please look into this to see if it is Runtime or update. Wassim, I understand the minimal launch approach and appreciate it. However, in this case, I have a product configuration and explicilty listed update.configurator in the confguration. Very few people will ever spec a dependency on that plugin as it is only "needed" if the higher level Update function is required. Please reconsider your notion of "minimal" to include, "is update.configurator in the ultimate target". I recall this to be the metric we had proposed originally anyway.
I am going to move the defect back to PDE/UI. The platform.xml does not look right. Need to investigate.
Jeff, what is the absolute path to your workpace where the problem occurs?
I am going to move to Update. PDE is programmatically generating the correct content and yet the platform.xml, particularly the site URLs, are wrong in the file on disk. As for whether 'minimal' should include update or not, 'Add Required plugins' which is ubiquitous in PDE never implied that "if update.configurator is in the target, add it". We don't want to go there either. I believe the story in >= 3.0 is that nothing is for free. The only liberty PDE takes is when generating the config.ini. If update.configurator is in the selected list, put it in charge of discovering the bundles. Otherwise, enumerate all the bundles in the config.ini. Is there a bug here wrt PDE synchronizing the product file and the launch config? If so, please open a separate defect and we'll address.
For me, the problem occurs only if the workspace for the host Eclipse in under the host Eclipse installation, eg. <eclipse_installation>/workspace.
My workspace is definitely not anywhere near my IDE install. never never never. The path is something like d:\book\chapter7. the IDE I'm running is d:\rc1\eclipse. Note that this happens in a mess of workspaces, not just one. I just did an experiment where I started with an empty/new workspace. using the new Hello world RCP wizard I created a plugin. Then I launched it from the Testing seciton in the plugin editor. The config.ini lists out all the plugins. This is good as update.configurator is not in the target. I then created a product from the launch config and launched it using the link in the Testing section of the product editor. The generated config.ini has all required plugins listed on the osgi.bundles list. This is good. Still no update.configurator involved. I then used the Configuration page of the product editor and added update.configurator to the list of plugins. saved, synchronized and launched again. This time the generated config.ini has only runtime and update.configurator on the osgi.bundles list, as expected but the application does not run as update fails to install my Test pluign. The generated platform.xml includes <site url="file:../../book/" enabled="true" updateable="true" policy="USER- INCLUDE" list="workspace/test/"> </site> This may be the cause of the problem. I believe there were some recent changes to update to make more of its information relative. Note that my workspace is acatully in d:\book\workspace and my IDE is in d:\rc1\eclipse and my target is c:\target\eclipse. The error message I get is !MESSAGE Could not install bundle ../../book/workspace/test/ c:\target\eclipse\..\..\book\workspace\test Note the path is c:\target\eclipse. It looks like the ..\ path is being computed relative to the wrong location since the workspace is very clearly on D not C. *** in any event, I carry on, optimistic that my sample app will in fact work if only I can run ti. I decide to export it using the link in the product editor. The resultant *generated* config.ini lists ALL the plugins rather than just runtime and update.configurator. Summary: The same style of config.ini generated for launching should be generated for building. so this really is too bugs. I can split if you like.
*** Bug 97138 has been marked as a duplicate of this bug. ***
*** Bug 97132 has been marked as a duplicate of this bug. ***
Any application other than the default (org.eclipse.ui.ide.workbench) fails to run if update.configurator is involved.
This problem warrants asking for an RC1 rebuild.
Branko, the recent fix for bug 94746 may have caused this problem. We need to get to the bottom of this.
Dorian, we need your help here because this is a super-sensitive area of the Update code.
In response to question in dupped bug 97132 comment #4, yes, org.eclipse.update.configurator is among those (by default) I'm launching with. If I uncheck it, I get different error messages, but no joy ... doubt you meant that as a work around, but if you'd like, I could attach log from that attempt.
thanks David. No I didn't mean that as a workaround. You need update.configurator for Junit plugin tests.
BTW, I agree with comment #3, RC1 should be re-done. I'd go so far to recommend it be pulled from download site, and a good test case added to cover these basic usage scenerios :)
opps, typo ... I meant comment #13
As the patch submitter, I will be looking into this as well.
Let's not worry about RC1 just yet. We need to get in order for the Tues test pass. Whatever we use for that can be labelled RC1a or some such so people know what "the good thing" is.
I am not sure Jeff's problem has the same cause, but the problem with having the workspace as a directory immediately under the install is caused by bug 97165, which went apparently unnoticed until the fix to bug 94746 was released.
Jeff's problem is unrelated to bug 97165. It is exactly what he has described in comment 9: the relative URL written to the platform.xml takes the currently running install (dev) as reference while when when running against the target the install URL will be the target.
Created attachment 21963 [details] patch for org.eclipse.update.configurator The attached patch prevents the configurator from transforming *site* URLs to relative URLs if the configuration is transient. This works around this issue and also bug 97165.
Created attachment 21966 [details] org.eclipse.update.configurator jar built with patch from comment #24 The patch works for my reproduced problem. For others to try it out - this is update configurator plug-in replacement.
Initial testing shows that this works for me.
It works for me, and also solves a related issue when you use .eclipsextension and links/.link files which makes sense to me.
Just to also confirm. I used the patched jar, and it solves my problems using RC1.
Re: comment 7 Philippe, this issue should manifest only during development time (launching an Eclipse from Eclipse). Was the problem you were seeing with external locations also related to launching Eclipse from Eclipse? If not, that might warrant a new PR.
My mistake. I was confused with some other stuffs. The links/eclipsextension stuffs works fine out of the box with an uptached RC1 :-)
Pls, have a look to bug 97390 i opened this morning. I think that somehow they are related.
*** Bug 97388 has been marked as a duplicate of this bug. ***
*** Bug 97390 has been marked as a duplicate of this bug. ***
You closed Bug 97390 as dup of this, but i wish to made you aware that i tested the patch proposed in comment #25 and is not solving that problem.
Patched released into HEAD.
Code released few days ago, so closing.
*** Bug 98647 has been marked as a duplicate of this bug. ***
*** Bug 98849 has been marked as a duplicate of this bug. ***
