Skip to main content



      Home
Home » Eclipse Projects » Eclipse Platform » RCP runtime classpath problems
RCP runtime classpath problems [message #270704] Wed, 08 September 2004 18:35 Go to next message
Eclipse UserFriend
Hi. I'm developing an RCP application and I've come to a halt on a runtime
classpath problem. The application has what I would guess to be a fairly
typical structure. There are three plugins, the first of which is the
main application and implements IPlatformRunnable, there's also a
WorkbenchAdvisor which creates the new perspective on first load. The
second plugin contains the perspective itself (i.e. it implements
IPerspectiveFactory) and during the call to createInitialLayout() the
services of a third plugin are required. However, a NoClassDefFoundError
is produced whenever anything from the third library plugin is referenced
from the perspective plugin. The library plugin has been added to the
"<requires>" section of the plugin.xml of both the main application and
perspective plugins. What else do I need to do?

Many thanks.
Henrietta
Re: RCP runtime classpath problems [message #270734 is a reply to message #270704] Thu, 09 September 2004 01:38 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: wassim.ibm.canada

Make sure the library from the third plug-in is marked as exported.

Wassim.

Henrietta wrote:

> Hi. I'm developing an RCP application and I've come to a halt on a runtime
> classpath problem. The application has what I would guess to be a fairly
> typical structure. There are three plugins, the first of which is the
> main application and implements IPlatformRunnable, there's also a
> WorkbenchAdvisor which creates the new perspective on first load. The
> second plugin contains the perspective itself (i.e. it implements
> IPerspectiveFactory) and during the call to createInitialLayout() the
> services of a third plugin are required. However, a NoClassDefFoundError
> is produced whenever anything from the third library plugin is referenced
> from the perspective plugin. The library plugin has been added to the
> "<requires>" section of the plugin.xml of both the main application and
> perspective plugins. What else do I need to do?

> Many thanks.
> Henrietta
Re: RCP runtime classpath problems [message #270757 is a reply to message #270734] Thu, 09 September 2004 03:37 Go to previous messageGo to next message
Eclipse UserFriend
Thanks Wassim.

How can I do what you suggest? I set the application and perspective
projects to "re-export" their library dependency but that doesn't make any
difference. In the third library plugin I have no dependencies to
export. I'd also like to solve this problem so that the library's class
directory is read directly (it's a big library and I don't want to
generate a jar after every build). Any ideas are most welcome.

Regards,
Henrietta

On Thu, 9 Sep 2004 05:38:32 +0000 (UTC), Wassim Melhem <wassim@ibm.canada>
wrote:

> Make sure the library from the third plug-in is marked as exported.
>
> Wassim.
>
> Henrietta wrote:
>
>> Hi. I'm developing an RCP application and I've come to a halt on a
>> runtime
>> classpath problem. The application has what I would guess to be a
>> fairly
>> typical structure. There are three plugins, the first of which is the
>> main application and implements IPlatformRunnable, there's also a
>> WorkbenchAdvisor which creates the new perspective on first load. The
>> second plugin contains the perspective itself (i.e. it implements
>> IPerspectiveFactory) and during the call to createInitialLayout() the
>> services of a third plugin are required. However, a
>> NoClassDefFoundError
>> is produced whenever anything from the third library plugin is
>> referenced
>> from the perspective plugin. The library plugin has been added to the
>> "<requires>" section of the plugin.xml of both the main application and
>> perspective plugins. What else do I need to do?
>
>> Many thanks.
>> Henrietta
>
>
Re: RCP runtime classpath problems [message #270797 is a reply to message #270757] Thu, 09 September 2004 10:24 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: richkulp.NO.SPAM.us.ibm.com

The library jar itself in the library plugin needs to be exported:

i.e.:

<runtime>
<library name="library.jar">
<export name="*"/>
</library>


If you don't do that, then even though you reference the library plugin,
the jar within the library is not visible to users of the plugin.

If your library plugin is a standard plugin project where you have the
source for the library and it is being compiled in the plugin project
then you don't need to jar it up for each time you make a change. When
you launch a Runtime Workspace from your Eclipse workspace to test your
plugins, the PDE automatically puts the bin directory onto the plugin's
classpath.


--
Thanks, Rich Kulp

Re: RCP runtime classpath problems [message #270812 is a reply to message #270797] Thu, 09 September 2004 10:50 Go to previous messageGo to next message
Eclipse UserFriend
Thanks - the library code does exist in a standard (OSGi) plugin and I too
was expecting PDE to automatically put the library's bin directory onto
the perspective plugin's classpath, but that is not happening. We're
working around the problem at the moment by generating a "library.jar"
file but this slows things down a lot and is prone to error.

I notice on the "Plugins don't work with MANIFEST.MF" thread that somebody
is suggesting "using the runtime tab of the plugin descriptor editor" to
"export all the needed classes". This is what I would like to do, but I'd
like to export the bin directory of the library project without jarring it
up first; is there any way to do that on the runtime tab? Could this be a
bug?


On Thu, 09 Sep 2004 10:24:32 -0400, Rich Kulp
<richkulp@NO.SPAM.us.ibm.com> wrote:

> The library jar itself in the library plugin needs to be exported:
>
> i.e.:
>
> <runtime>
> <library name="library.jar">
> <export name="*"/>
> </library>
>
>
> If you don't do that, then even though you reference the library plugin,
> the jar within the library is not visible to users of the plugin.
>
> If your library plugin is a standard plugin project where you have the
> source for the library and it is being compiled in the plugin project
> then you don't need to jar it up for each time you make a change. When
> you launch a Runtime Workspace from your Eclipse workspace to test your
> plugins, the PDE automatically puts the bin directory onto the plugin's
> classpath.
>
>
Re: RCP runtime classpath problems [message #270834 is a reply to message #270812] Thu, 09 September 2004 11:19 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: richkulp.NO.SPAM.us.ibm.com

I don't know, I don't use the Manifest. I still stick with the
plugin.xml form because that works great with the PDE. The PDE is being
advanced to work with the Manifest form of a plugin but I don't think it
is quite there yet, last I heard. :-) If I use the plugin.xml form I've
never had such a problem.


--
Thanks, Rich Kulp

Re: RCP runtime classpath problems [message #270846 is a reply to message #270834] Thu, 09 September 2004 11:40 Go to previous messageGo to next message
Eclipse UserFriend
When you say that you "still stick with the plugin.xml" (which is what I
think I'm doing - the manifest was created and appears to be maintained
automagically), do you do rely on the following section:

<requires>
<import plugin="Library"/>
</requires>

and then just get the bin directory for "Library" appearing on your
classpath at runtime? This is what I'm doing in 3.1M1 and it doesn't
work, so if your having success with this in an earlier Eclipse version
I'll file a bugzilla.

Thanks.


On Thu, 09 Sep 2004 11:19:07 -0400, Rich Kulp
<richkulp@NO.SPAM.us.ibm.com> wrote:

> I don't know, I don't use the Manifest. I still stick with the
> plugin.xml form because that works great with the PDE. The PDE is being
> advanced to work with the Manifest form of a plugin but I don't think it
> is quite there yet, last I heard. :-) If I use the plugin.xml form I've
> never had such a problem.
>
>
Re: RCP runtime classpath problems [message #270849 is a reply to message #270846] Thu, 09 September 2004 11:46 Go to previous messageGo to next message
Eclipse UserFriend
P.S. The <requires> section is all that is created when you "Add..." the
library plugin from the dependencies section of the plugin.xml form.

On Thu, 09 Sep 2004 16:40:23 +0100, Henrietta
<henrietta_slack@hotmail.com> wrote:

>
> When you say that you "still stick with the plugin.xml" (which is what I
> think I'm doing - the manifest was created and appears to be maintained
> automagically), do you do rely on the following section:
>
> <requires>
> <import plugin="Library"/>
> </requires>
>
> and then just get the bin directory for "Library" appearing on your
> classpath at runtime? This is what I'm doing in 3.1M1 and it doesn't
> work, so if your having success with this in an earlier Eclipse version
> I'll file a bugzilla.
>
> Thanks.
>
>
> On Thu, 09 Sep 2004 11:19:07 -0400, Rich Kulp
> <richkulp@NO.SPAM.us.ibm.com> wrote:
>
>> I don't know, I don't use the Manifest. I still stick with the
>> plugin.xml form because that works great with the PDE. The PDE is being
>> advanced to work with the Manifest form of a plugin but I don't think
>> it is quite there yet, last I heard. :-) If I use the plugin.xml form
>> I've never had such a problem.
>>
>>
>
Re: RCP runtime classpath problems [message #270860 is a reply to message #270834] Thu, 09 September 2004 12:11 Go to previous messageGo to next message
Eclipse UserFriend
Fixed it! I deleted the manifests and manually added "bin/" to the
runtime tab and I can now happily remove my library jar files.

Thanks for the help.

On Thu, 09 Sep 2004 11:19:07 -0400, Rich Kulp
<richkulp@NO.SPAM.us.ibm.com> wrote:

> I don't know, I don't use the Manifest. I still stick with the
> plugin.xml form because that works great with the PDE. The PDE is being
> advanced to work with the Manifest form of a plugin but I don't think it
> is quite there yet, last I heard. :-) If I use the plugin.xml form I've
> never had such a problem.
>
>
Re: RCP runtime classpath problems [message #270970 is a reply to message #270834] Thu, 09 September 2004 23:05 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: wassim.ibm.canada

Rich, who have you been talking to? :-)

The PDE editor will work great whether you have a plugin.xml/manifest.mf
combo or when you only have one of these files.

The difference is that in a plugin.xml, you can actually mark the library
as exported in one shot with <export name="*"/>.
OSGi does not support such a mechanism. If you need to export a library,
you need to explicitly enumerate all packages in the library.

This is not a PDE limitation, it's what the runtime expects. The PDE
editor supports both scenarios.

Wassim.


Rich Kulp wrote:

> I don't know, I don't use the Manifest. I still stick with the
> plugin.xml form because that works great with the PDE. The PDE is being
> advanced to work with the Manifest form of a plugin but I don't think it
> is quite there yet, last I heard. :-) If I use the plugin.xml form I've
> never had such a problem.
Re: RCP runtime classpath problems [message #271036 is a reply to message #270970] Fri, 10 September 2004 13:52 Go to previous message
Eclipse UserFriend
Originally posted by: richkulp.NO.SPAM.us.ibm.com

I guess it was because the last time I tried was like M8 or something.
It didn't seem to have fields yet for working with manifests. And I
heard of other problems then too.

My apologies to everyone. :-)

Wassim Melhem wrote:

> Rich, who have you been talking to? :-)
>
> The PDE editor will work great whether you have a plugin.xml/manifest.mf
> combo or when you only have one of these files.
>

--
Thanks, Rich Kulp

Previous Topic:need to open editor on file outside of workspace
Next Topic:Feature exporting problems reported in log file
Goto Forum:
  


Current Time: Fri May 09 06:58:09 EDT 2025

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

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

Back to the top