[go: up one dir, main page]

Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Plugin Development Environment (PDE) » Possible Classpath Issue when Galilieo plugin moved to Helios
Possible Classpath Issue when Galilieo plugin moved to Helios [message #606469] Mon, 16 August 2010 14:27 Go to next message
Andy is currently offline AndyFriend
Messages: 47
Registered: July 2009
Member
I have a plugin that I developed in Galileo. It works fine while running it from within Galileo, both from within the development environment (right mouse on plugin.xml and select run) and also when I install it in a clean instance of Galileo as a plugin from my eclipse update site.

When I moved my project into Helios the plugin worked fine when launched from within Helios' development environment (right mouse plugin.xml and select run), but if I packaged it up and then tried to install it from the update site it would just hang the plugin. I looked in the eclipse .log for a stack trace and noticed the stack trace below.

The part that is most confusing to me is that even though both times it is run in Helios it apparently acts differently based on the way it is started. In looking at the log it would appear that classpaths are handled correctly when the plugin is launched in the dev environment but when installed into Helios there is some other version of HttpMethod in the classpath that is throwing a mismatch.

Am I doing something wrong or is this a bug? Did classpath handling get changed from Galileo to Helios?

!ENTRY org.eclipse.ui 4 0 2010-08-13 15:35:36.916
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.IncompatibleClassChangeError: Class com.mycompany.vfs.utils.PropfindMethod does not implement the requested interface org.apache.commons.httpclient.HttpMethod
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpC lient.java:383)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpC lient.java:323)
at com.mycompany.vfs.utils.FileTransportManager.checkURLValidit y(FileTransportManager.java:1368)
at com.mycompany.vfs.dialogs.AddRepositoryDialog$1.widgetSelect ed(AddRepositoryDialog.java:255)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:234)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:4066)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3657)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825 )
at org.eclipse.jface.window.Window.open(Window.java:801)
at com.mycompany.vfs.actions.AddRepositoryAction.run(AddReposit oryAction.java:47)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498 )
at org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:584)
at org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:501)
at org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:4066)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3657)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2629)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2593)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:24 27)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:670)
at org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:663)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:115)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:369)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 619)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
Re: Possible Classpath Issue when Galilieo plugin moved to Helios [message #606481 is a reply to message #606469] Wed, 18 August 2010 19:07 Go to previous messageGo to next message
Andy is currently offline AndyFriend
Messages: 47
Registered: July 2009
Member
Figured out some more information that might help some others out.

Apparently Eclipse ships with two jar files that are almost exactly the same (in the plugins directory):

org.apache.commons.httpclient_3.1.0.v201005080502.jar

and

org.apache.commons.httpclient_3.1.0.v20080605-1935.jar

I found that when I removed the more recent of the two jars, amazingly my plugin started working again. This doesn't seem like the best solution since there could be other things in Eclipse that use this jar file.

So, I guess why does Eclipse ship with two jar files that are almost exactly identical? It appears that Eclipse is ignoring the reference in my plugin to the 2008 version of the jar and instead just uses the one from 2010, which is the wrong thing for Eclipse to do.

I also noticed that two more jar files are duplicated:

org.apache.commons.codec_1.3.0.v20100106-1700.jar
org.apache.commons.codec_1.3.0.v20100518-1140.jar

org.apache.commons.logging_1.0.4.v200904062259.jar
org.apache.commons.logging_1.0.4.v201005080501.jar


Any ideas as to how to get Eclipse to listen to what I specify in my plugin? Is this a bug? Should these jars be duplicated?
Re: Possible Classpath Issue when Galilieo plugin moved to Helios [message #606483 is a reply to message #606469] Wed, 18 August 2010 21:28 Go to previous messageGo to next message
Andy is currently offline AndyFriend
Messages: 47
Registered: July 2009
Member
I just unzipped the Eclipse RCP zip file eclipse-rcp-helios-win32.zip and the duplicates definitely are there.
Re: Possible Classpath Issue when Galilieo plugin moved to Helios [message #606496 is a reply to message #606469] Mon, 23 August 2010 13:53 Go to previous message
Andy is currently offline AndyFriend
Messages: 47
Registered: July 2009
Member
Bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=323154
Previous Topic:Possible Classpath Issue when Galilieo plugin moved to Helios
Next Topic:Renaming plugin package causes extension problems with updates
Goto Forum:
  


Current Time: Thu Dec 12 18:48:05 GMT 2024

Powered by FUDForum. Page generated in 0.03278 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top