Re: Lintian Override for OSGi classpath in Freeplane?
On 2011-06-04 13:27, Eric Lavarde wrote:
> I'm not a big OSGi specialist, but let me give back what I understand:
> On 04/06/11 12:16, Niels Thykier wrote:
>> Lintian already skips the Class-Path check if the Manifest has a
>> Bundle-SymbolicName entry (which all OSGi bundles should have as I
>> 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
> 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.
Technically, you can promote them to real OSGi bundles and patch the
Manifest to load them as such; that being said, the unpacked OSGi bundle
solution is vastly easier when the bundle does not contain class files
> For this reason, I asked upstream to unpack the OSGi jar files, which
> they kindly did. The result is the following structure:
> 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
> The structure with ./lib/*.jar and ./META-INF/MANIFEST.INF in the same
> directory is, as far as I understand, only a coincidental convention,
Indeed, I have seen jar files in the root of OSGi-bundle.
> but perhaps we could make it a Debian-Java rule?!
I would rather not diverge from Upstream here, especially not when
Bundle-Classpath allows it.
> 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!?
It complains about the "../" part in freeplaneeditor.jar, which would be
a relative path to a directory, which seems to be a genuine issue.
I will have the next version of Lintian only print the "bad" parts of
the classpath, which makes this easier to spot.
I cannot see any further issues in freeplane currently, so I am inclined
to keep status quo for now and patch Lintian as needed.
Particularly I hope we have more OSGi experience and can make better
decisions for these cases at that time.
> Hope this helps,