Eclipse Community Forums: Plugin Development Environment (PDE) » Possible Classpath Issue when Galilieo plugin moved to Helios

Home » Eclipse Projects » Plugin Development Environment (PDE) » Possible Classpath Issue when Galilieo plugin moved to Helios(Plugin works fine in Galileo and Helios Dev Environment, fails when installed in Helios)

Show: Today's Messages :: Show Polls :: Message Navigator

Possible Classpath Issue when Galilieo plugin moved to Helios [message #553128]

Mon, 16 August 2010 14:27

Andy

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)

Report message to a moderator

Re: Possible Classpath Issue when Galilieo plugin moved to Helios [message #553770 is a reply to message #553128]

Wed, 18 August 2010 19:07

Andy

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?

Report message to a moderator

Re: Possible Classpath Issue when Galilieo plugin moved to Helios [message #553787 is a reply to message #553770]

Wed, 18 August 2010 21:03

Bruce Kelly

Messages: 63
Registered: July 2009

Member

I'm using Eclipse classic and there is only one copy of the jar files.

Namaste, Bruce.

"Andy" <andrewnbenjamin@hotmail.com> wrote in message
news:i4hb1e$7tr$1@build.eclipse.org...
> 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?

Report message to a moderator