Re: Lintian Override for OSGi classpath in Freeplane?
On 2011-06-04 09:52, Eric Lavarde wrote:
> Hello,
>
> while repackaging Freeplane, I noticed that there a few new Lintian
> checks in regard to Java...
>
> I had first the warning:
>
> W: freeplane: classpath-contains-relative-path
> usr/share/freeplane/core/org.freeplane.core/lib/freeplaneeditor.jar: ../
> freeplaneeditor.jar freeplaneviewer.jar freeplanemac.jar
> commons-lang-2.0.jar forms-1.0.5.jar jortho.jar gnu-regexp-1.1.4.jar
> SimplyHTML.jar
>
> Then I patched away the Class-path, and got:
>
> W: freeplane: missing-classpath libcommons-lang-java,
> libjgoodies-forms-java, libbatik-java, libxerces2-java,
> libxml-commons-external-java, libjaxp1.3-java, libjlatexmath-java,
> libknopflerfish-osgi-framework-java, libjortho-freeplane-java
>
> Two issues with this:
>
> 1. the help message to classpath-contains-relative-path could more
> explicitly state what the resolution is or isn't (in this case, NOT
> remove the classpath BUT use absolute path).
> I can log a (minor) bug for this one if you want. Against lintian I guess?
>
Please do, I have been meaning to fix that, but a bug is always a good
reminder. The real problem is usually class-paths like "lib/$file.jar"
or "usr/share/java/$file.jar" which does not work as intended when the
jar file is installed in /usr/share/java.
That being said, this check needs to be refined (e.g. jars in private
packages might have a lib/ dir with symlinks to the actual files, which
would work correctly).
> 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?
~Niels
Reply to: