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 -- 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/4dea05ee.8070...@thykier.net
