On 2011-06-04 13:27, Eric Lavarde wrote: > 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: >>> [...] >> 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. >
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 itself. > 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 > 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, 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, > Eric > > ~Niels -- 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/4dea2006.2040...@thykier.net
