Hello,
I'm not a big OSGi specialist, but let me give back what I understand:
On 04/06/11 12:16, Niels Thykier wrote:
2. my actual problem is that the classpath is actually not needed by
> Freeplane because it uses Knopflerfish / OSGi framework which resolves
> itself dependencies based on
> /usr/share/freeplane/core/org.freeplane.core/META-INF/MANIFEST.MF (and
> to make it even more fun, anyway doesn't accept absolute paths, already
> tried).
> Sounds to me like a case for a Lintian override, any other opinion?
>
> Thanks, Eric
>
>
Lintian already skips the Class-Path check if the Manifest has a
Bundle-SymbolicName entry (which all OSGi bundles should have as I
understand).
But I have no idea of how this would work for an application that uses
OSGi; I would assume it would need a Class-Path entry for the OSGi
providing library and take things from there.
Is there some (fairly) trivial way we can check if an application uses
OSGi?
Originally, upstream had packaged the "standard" jar files in "OSGi" jar
files, but that meant that also the depended-on libraries were to be in
the OSGi jar files, which made proper packaging barely impossible.
For this reason, I asked upstream to unpack the OSGi jar files, which
they kindly did. The result is the following structure:
$ dpkg -L freeplane | grep org.freeplane
/usr/share/freeplane/core/org.freeplane.core
/usr/share/freeplane/core/org.freeplane.core/META-INF
/usr/share/freeplane/core/org.freeplane.core/META-INF/MANIFEST.MF
/usr/share/freeplane/core/org.freeplane.core/lib
/usr/share/freeplane/core/org.freeplane.core/lib/freeplaneviewer.jar
/usr/share/freeplane/core/org.freeplane.core/lib/freeplaneeditor.jar
/usr/share/freeplane/core/org.freeplane.core/lib/freeplaneosgi.jar
/usr/share/freeplane/plugins/org.freeplane.plugin.script
/usr/share/freeplane/plugins/org.freeplane.plugin.script/META-INF
/usr/share/freeplane/plugins/org.freeplane.plugin.script/META-INF/MANIFEST.MF
/usr/share/freeplane/plugins/org.freeplane.plugin.script/lib
/usr/share/freeplane/plugins/org.freeplane.plugin.script/lib/plugin.jar
/usr/share/freeplane/plugins/org.freeplane.plugin.svg
/usr/share/freeplane/plugins/org.freeplane.plugin.svg/META-INF
/usr/share/freeplane/plugins/org.freeplane.plugin.svg/META-INF/MANIFEST.MF
/usr/share/freeplane/plugins/org.freeplane.plugin.svg/lib
/usr/share/freeplane/plugins/org.freeplane.plugin.svg/lib/plugin.jar
/usr/share/freeplane/plugins/org.freeplane.plugin.latex
/usr/share/freeplane/plugins/org.freeplane.plugin.latex/META-INF
/usr/share/freeplane/plugins/org.freeplane.plugin.latex/META-INF/MANIFEST.MF
/usr/share/freeplane/plugins/org.freeplane.plugin.latex/lib
/usr/share/freeplane/plugins/org.freeplane.plugin.latex/lib/plugin.jar
Each jar file listed has also a minimal (dummy?) manifest embedded, but
the real one is the one in the filesystem, as listed above.
The good news is that each of these real manifests has the symbolic name
Bundle-SymbolicName.
The structure with ./lib/*.jar and ./META-INF/MANIFEST.INF in the same
directory is, as far as I understand, only a coincidental convention,
but perhaps we could make it a Debian-Java rule?!
Then the check could become:
1. jar file doesn't have a class-path entry, or only a relative one.
2. is there a file ../META-INF/MANIFEST.MF that contains a
Bundle-SymbolicName entry?
2a. you could also / alternatively check that there is an entry
Bundle-ClassPath that refers to this same library, but that's more work
for a dubious added value.
3. If yes, ignore (or downgrade warning to pedantic with note that it's
probably anyway an OSGi bundle)
A strange thing is that Lintian does only complain about
freeplaneeditor.jar and not about the other jar files!?
Hope this helps,
Eric
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dea1698.5050...@zorglub.s.bawue.de
