Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [linux-distros-dev] Gentoo packager / maintainer for Eclipse

Hi,

On Wed, 2008-04-23 at 15:38 +0200, Jean-Noël Rivasseau wrote:
>         > In particular, my last post on the forums,
>         >
>         >
>         http://www.eclipse.org/newsportal/article.php?id=74374&group=eclipse.platform#74374
>         >
>         > has not been answered so far, so any help is appreciated.
>         
>         
>         I'm not a newsgroup guy myself.  Looking at your post, have
>         you
>         considered working with the Orbit project to keep these
>         third-party
>         libraries updated at eclipse.org?
>         
>         As for the issue you're seeing, it's complicated and I don't
>         fully
>         understand it myself.  How did you "fiddle with the manifest
>         in the
>         Junit 4 bundle to include a dependency to our local system
>         hamcrest
>         jar"? 
> 
> I added an Import-Package directive.

Hmm.  Have you looked at the way that Mylyn does its web.core (in its
MANIFEST.MF)?

Bundle-ClassPath: lib-httpclient/commons-httpclient-3.1.jar,
 lib-httpclient/commons-codec-1.3.jar,
 lib-httpclient/commons-logging-1.0.4.jar,
 lib-httpclient/commons-logging-api-1.0.4.jar,
 lib-xmlrpc/xmlrpc-client-3.0.jar,
 lib-xmlrpc/xmlrpc-common-3.0.jar,



>         Perhaps it's the way you
>         added it to the MANIFEST.MF of the bundle.  Does the hamcrest
>         JAR you
>         have on your system have OSGi metadata in it?  If so, couldn't
>         you just
>         add it as a bundle and make the junit4 bundle "Require-bundle"
>         or
>         "Import-package" it?
> yes, the hamcrest jar has meta data in it.

Can you send it my way?
 
>         
>         
>         We (Fedora) run the Equinox FileInitializer application to
>         pre-initialize our system-wide arch-specific directory
>         (/usr/lib{,64}/eclipse in this case) with shared libraries
>         (.sos).  If
>         the above doesn't work, you could try doing that with the .jar
>         file in
>         this case.
> 
> I am not sure the issue is related to native shared libraries. I am
> pretty sure it's an OSGi problem / jar problem.

I didn't mean it was a problem with shared libraries.  I was unclear.  I
was just saying that if you can't get symlinking the jar to work, you
could always pre-extract it with the initializer app like we do
for .sos.  But I think that's not the issue here.

> What contacts do you have upstream that could help me with this?

Let's see if we can sort this out before resorting to bugging them :)

Andrew



Back to the top