[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
  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


Reply to: