* Pascal Rapicault <Pascal_Rapicault(a)ca.ibm.com> [2007-03-28 21:20]:
> This is for a simple overview, there are other refinements (mostly around
> the use clause) that I won't go into here and that you can find in the OSGi
> spec: http://osgi.org/osgi_technology/download_specs.asp?section=2#Release4
Thanks for the clarification, Pascal.
I guess you could liken import to just relying on a non-package name
Provide of an RPM -- something like what we're trying to for with these
automatic provides. You could say "Requires: libgcj.so.7rh" instead of
"Requires: libgcj" or "Requires: libgcj = 4.1.1". But I think this is
different than what you describe and I don't know how yum or other
depsolvers deal with multiple packages Provide'ing the same thing.
Andrew "poor explanation" Overholt
We'd like Eclipse packages (which we want to extend to all OSGi
packages and then to whatever module system Sun puts into Java 7 or 8)
to have RPM automatically generate Provides and Requires. This is
similar to how it's done for DSOs or perl, python, or mono modules.
$ rpm -q --requires tomboy
[I've stripped the non-mono requirements]
mono(glib-sharp) = 18.104.22.168
mono(gnome-sharp) = 22.214.171.124
mono(gtk-sharp) = 126.96.36.199
$ rpm -q --provides gnome-sharp
mono(gnome-sharp) = 188.8.131.52
I imagine this will manifest itself in a shell script to run over jars
in a certain location and extract their META-INF/MANIFEST.MF and parse
out the OSGi provides and requires. It would of course be better to do
this as an OSGi app but I wonder how the RPM guys would feel about
having an Eclipse or Java dependency.
I don't think we want to do something like java(modulename) yet, but
just having it automatically generate these lists would get us a long
Anyone have any thoughts?
Kyu Lee is going to investigate this and will keep us posted as he
Hi Fernando / Deepack,
I'd like to add OSGi manifests to the jars of Eclipse dependencies so
that Eclipse can link to the system installed jars rather than keeping a
copy of these dependencies in /usr/share/eclipse. The general strategy
for doing this would be as follows:
* add the OSGi bundle or Manifest from Orbit as an additional source to
* build the jar like normal
* extract (if required) and inject the OSGi Manifest to the original jar
For Eclipse 3.2.2 / F7, there are two packages that need to be moved out
of the eclipse rpm: jsch and icu4j. The jsch build can use the method
described above (see attached patch) but I think we should use a
different approach for icu4j since the OSGi jar can be compiled
directly. In this case I'd like to use the OSGi jar directly and add
links for the regular jars. I would need to check the OSGi build and the
regular build end up with the same class files but I'm pretty sure they
Anyway, let me know what you think so that I can commit the jsch patch
and move on to icu4j.
On Wed, 2007-03-28 at 21:18 -0400, Pascal Rapicault wrote:
> If it helps, note that the manifests are directly available in the Orbit
> repository thus saving you the extraction / injection.
Looking at jsch, it doesn't seem like the the manifest is actually in
cvs - only the jar is checked it:
I'll just stick with extracting the manifest from the jar for now.
eclipse-mylar and eclipse-sdk-nls have finally hit rawhide! They should
probably show up on mirrors sometime tomorrow.
Thanks to Kyu Lee who did all the work on the translations. He just
showed me the SDK running with the Korean translations and it's pretty
As for Mylar, I'm aware of class library issues with gcj and I'm
tracking them down now. Filing bugs would help with this as I'm sure I
won't exercise all code paths. Thanks to Anthony and others who helped
make this happen.
* Pascal Rapicault <Pascal_Rapicault(a)ca.ibm.com> [2007-03-27 22:24]:
> If you are ok with running java code to generate your RPM metadata
Unfortunately I doubt that this will be acceptable to the RPM people.
Thanks for the pointers anyway, though :)
> Also, as a point of interest for me, does RPM has the ability to express
> constraints similar to import and export?
I'm confused as to what import does that is different from requires.
Can you please elaborate or tell me what to read?
Export I guess you could compare with Provides in RPM parlance. Anyone
else have thoughts on this? For those that don't know -- and please
correct me if I'm wrong -- Export is used to limit what java package
names are visible to other bundles.
(also posted to fedora-devel)
- Who should own /usr/share/java? Currently there is:
and that's just from core.
- Where should JNI libraries be installed? plplot wants to install into
/usr/lib/jni, but that doesn't look like it's used by anyone else.
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
I've been trying to build mylar for inclusion in F7. It's not going too
well due to difficulties with generating the build.xmls, etc. I may
have a stop-gap for that, but now I'm hitting the problem of its
dependencies not being in Fedora or JPackage. The jars it needs are (all in
I *think* we're fine with the above, but the next one I'm worried about:
I don't see this anywhere in JPackage or Fedora. Does anyone know if there
is an RPM of it somewhere? Anyone familiar with it or with packaging enough
to cook something up in the next few days?
The new gcj package with version 5 libraries and compiler has been
available in rawhide for a couple of weeks now.
This package is available from the yum development repo as
If you are a maintainer of a package that has a dependency on libgcj
please make sure that your package builds. I don't expect there to be
many problems, but it's worth checking.