FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Java

 
 
LinkBack Thread Tools
 
Old 06-04-2011, 07:52 AM
Eric Lavarde
 
Default Lintian Override for OSGi classpath in Freeplane?

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?

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


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DE9E453.7060400@zorglub.s.bawue.de">http://lists.debian.org/4DE9E453.7060400@zorglub.s.bawue.de
 
Old 06-04-2011, 10:16 AM
Niels Thykier
 
Default 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


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DEA05EE.8070603@thykier.net">http://lists.debian.org/4DEA05EE.8070603@thykier.net
 
Old 06-04-2011, 11:27 AM
Eric Lavarde
 
Default Lintian Override for OSGi classpath in Freeplane?

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:

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


For this reason, I asked upstream to unpack the OSGi jar files, which
they kindly did. The result is the following structure:


$ dpkg -L freeplane | grep org.freeplane
/usr/share/freeplane/core/org.freeplane.core
/usr/share/freeplane/core/org.freeplane.core/META-INF
/usr/share/freeplane/core/org.freeplane.core/META-INF/MANIFEST.MF
/usr/share/freeplane/core/org.freeplane.core/lib
/usr/share/freeplane/core/org.freeplane.core/lib/freeplaneviewer.jar
/usr/share/freeplane/core/org.freeplane.core/lib/freeplaneeditor.jar
/usr/share/freeplane/core/org.freeplane.core/lib/freeplaneosgi.jar
/usr/share/freeplane/plugins/org.freeplane.plugin.script
/usr/share/freeplane/plugins/org.freeplane.plugin.script/META-INF
/usr/share/freeplane/plugins/org.freeplane.plugin.script/META-INF/MANIFEST.MF
/usr/share/freeplane/plugins/org.freeplane.plugin.script/lib
/usr/share/freeplane/plugins/org.freeplane.plugin.script/lib/plugin.jar
/usr/share/freeplane/plugins/org.freeplane.plugin.svg
/usr/share/freeplane/plugins/org.freeplane.plugin.svg/META-INF
/usr/share/freeplane/plugins/org.freeplane.plugin.svg/META-INF/MANIFEST.MF
/usr/share/freeplane/plugins/org.freeplane.plugin.svg/lib
/usr/share/freeplane/plugins/org.freeplane.plugin.svg/lib/plugin.jar
/usr/share/freeplane/plugins/org.freeplane.plugin.latex
/usr/share/freeplane/plugins/org.freeplane.plugin.latex/META-INF
/usr/share/freeplane/plugins/org.freeplane.plugin.latex/META-INF/MANIFEST.MF
/usr/share/freeplane/plugins/org.freeplane.plugin.latex/lib
/usr/share/freeplane/plugins/org.freeplane.plugin.latex/lib/plugin.jar

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,
but perhaps we could make it a Debian-Java rule?!


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


Hope this helps,
Eric


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DEA1698.5050704@zorglub.s.bawue.de">http://lists.debian.org/4DEA1698.5050704@zorglub.s.bawue.de
 
Old 06-04-2011, 12:07 PM
Niels Thykier
 
Default Lintian Override for OSGi classpath in Freeplane?

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DEA2006.2040700@thykier.net">http://lists.debian.org/4DEA2006.2040700@thykier.net
 
Old 06-04-2011, 12:43 PM
Eric Lavarde
 
Default Lintian Override for OSGi classpath in Freeplane?

On 04/06/11 14:07, Niels Thykier wrote:

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.
But once I've patched away the class-path entry, it complains about a
missing class-path, and no jar file in Freeplane has actually a class-path!?



I cannot see any further issues in freeplane currently, so I am inclined
to keep status quo for now and patch Lintian as needed.

I'll add an override in the mean time.


Particularly I hope we have more OSGi experience and can make better
decisions for these cases at that time.

Fine with me.

Eric


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DEA288F.1070502@zorglub.s.bawue.de">http://lists.debian.org/4DEA288F.1070502@zorglub.s.bawue.de
 
Old 06-04-2011, 12:54 PM
Niels Thykier
 
Default Lintian Override for OSGi classpath in Freeplane?

On 2011-06-04 14:43, Eric Lavarde wrote:
> On 04/06/11 14:07, Niels Thykier wrote:
>>> 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.
> But once I've patched away the class-path entry, it complains about a
> missing class-path, and no jar file in Freeplane has actually a
> class-path!?
>

Not the entire classpath, only the "../" entry of it.

>> I cannot see any further issues in freeplane currently, so I am inclined
>> to keep status quo for now and patch Lintian as needed.
> I'll add an override in the mean time.
>

Actually could you test it with Lintian from the current git master?
Note that the new Lintian will only output the "wrong" parts of a
class-path entry, so the output will differ here.

>> Particularly I hope we have more OSGi experience and can make better
>> decisions for these cases at that time.
> Fine with me.
>
> Eric
>
>

~Niels


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DEA2AFC.20804@thykier.net">http://lists.debian.org/4DEA2AFC.20804@thykier.net
 
Old 06-05-2011, 11:07 AM
Eric Lavarde
 
Default Lintian Override for OSGi classpath in Freeplane?

On 04/06/11 14:54, Niels Thykier wrote:

On 2011-06-04 14:43, Eric Lavarde wrote:

But once I've patched away the class-path entry, it complains about a
missing class-path, and no jar file in Freeplane has actually a
class-path!?


Not the entire classpath, only the "../" entry of it.

I meant actually the following error:
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


But I now realize that it doesn't complain about a specific jar file,
but that NONE does refer to those libraries...



I cannot see any further issues in freeplane currently, so I am inclined
to keep status quo for now and patch Lintian as needed.

I'll add an override in the mean time.


Actually could you test it with Lintian from the current git master?
Note that the new Lintian will only output the "wrong" parts of a
class-path entry, so the output will differ here.

If it's simple and you tell me how :-)

Eric


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DEB6386.9090004@zorglub.s.bawue.de">http://lists.debian.org/4DEB6386.9090004@zorglub.s.bawue.de
 
Old 06-05-2011, 12:46 PM
Eric Lavarde
 
Default Lintian Override for OSGi classpath in Freeplane?

On 05/06/11 13:07, Eric Lavarde wrote:

Actually could you test it with Lintian from the current git master?
Note that the new Lintian will only output the "wrong" parts of a
class-path entry, so the output will differ here.

If it's simple and you tell me how :-)

Eric

Answering to myself, uuh, bad! ;-)

I tried to download the last snapshot from
http://anonscm.debian.org/gitweb/?p=lintian/lintian.git
The one from Extending the checks for dh_make templates:
http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=snapshot;h=ed14452f24120d4676ec199ab 15f1a8bfce9abc5;sf=tgz

Tried to 'dpkg-buildpackage -r fakeroot' it in my unstable chroot and got:
[...]
Running scripts-ocamlrun 1.0... building... testing... ok.
Running shared-libs-exec-bit 1.0... building... testing... ok.
Running shared-libs-control-file 1.0... building... testing... ok.
Running shared-libs-la-files 1.0... building... testing... ok.
Running shared-libs-non-pic-i386 1.0... building... testing... ok.
Running shared-libs-ldconfig-scripts 1.0... building... testing... ok.
Running shared-libs-unversioned 1.0... building... testing... ok.
Running shared-libs-symbols-file 1.0-1... building... testing... FAILED:
--- t/tests/shared-libs-symbols-file/tags 2011-06-04
23:59:23.000000000 +0200
+++ debian/tests/shared-libs-symbols-file/tags.shared-libs-symbols-file
2011-06-05 13:47:45.000000000 +0200

@@ -1,5 +1,9 @@
E: libfoo1: symbols-file-contains-current-version-with-debian-revision
on symbol e@Base

E: nolibrary: pkg-has-symbols-control-file-but-no-shared-libs
I: libsym1: no-symbols-control-file usr/lib/libsym.so.1.0.1
+W: libesym1: gz-file-not-gzip usr/share/doc/libesym1/changelog.Debian.gz
W: libesym1: shlib-missing-in-symbols-control-file libesym 1 for
usr/lib/libesym.so.1.0.1

+W: libfoo1: gz-file-not-gzip usr/share/doc/libfoo1/changelog.Debian.gz
W: libfoo1: symbols-file-contains-debian-revision on symbol energy@Base
+W: libsym1: gz-file-not-gzip usr/share/doc/libsym1/changelog.Debian.gz
+W: nolibrary: gz-file-not-gzip usr/share/doc/nolibrary/changelog.Debian.gz
Running spelling-general 1.0... building... testing... ok.
Running spelling-multiword 1.0... building... testing... ok.
Running spelling-package-name 1.0... building... testing... ok.
Running standards-version-invalid 1.0... building... testing... ok.
Running standards-version-newer 1.0... building... testing... ok.
Running standards-version-old 1.0... building... testing... ok.
Running standards-version-timewarp 1.0... building... testing... ok.
Running standards-version-timewarp-unrel 1.0... building... testing... ok.
Running symlinks-broken 1.0... building... testing... ok.
Running version-substvars-general 1.0... building... testing... ok.
Running watch-file-general 2.0.ds1-1... building... testing... ok.
Running watch-file-native 1.0... building... testing... ok.
Running watch-file-no-version 1.0-1... building... testing... ok.
Running watch-file-old-upstream-version 2.0-1... building... testing... ok.
Running watch-file-prerelease 1~rc1-1... building... testing... ok.
Running watch-file-should-mangle 1+dfsg-1... building... testing... ok.
Running watch-file-template 1.0-1... building... testing... ok.
Running generic-dh-make-2005 1-1... building... testing... ok.
Running generic-dh-make-2008 1.0-1... building... testing... ok.
Running generic-empty 1.0... building... testing... ok.
make: *** [runtests] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2

I gave up at this stage,
Eric


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DEB7A8A.30305@zorglub.s.bawue.de">http://lists.debian.org/4DEB7A8A.30305@zorglub.s.bawue.de
 
Old 06-05-2011, 12:47 PM
Niels Thykier
 
Default Lintian Override for OSGi classpath in Freeplane?

On 2011-06-05 13:07, Eric Lavarde wrote:
> On 04/06/11 14:54, Niels Thykier wrote:
>> On 2011-06-04 14:43, Eric Lavarde wrote:
>>> But once I've patched away the class-path entry, it complains about a
>>> missing class-path, and no jar file in Freeplane has actually a
>>> class-path!?
>>
>> Not the entire classpath, only the "../" entry of it.
> I meant actually the following error:
> 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
>
> But I now realize that it doesn't complain about a specific jar file,
> but that NONE does refer to those libraries...
>

Yeah, I tested the old freeplane package (in testing) and the only
issue I saw with its classpath was it had a "../".

>>>> I cannot see any further issues in freeplane currently, so I am
>>>> inclined
>>>> to keep status quo for now and patch Lintian as needed.
>>> I'll add an override in the mean time.
>>
>> Actually could you test it with Lintian from the current git master?
>> Note that the new Lintian will only output the "wrong" parts of a
>> class-path entry, so the output will differ here.
> If it's simple and you tell me how :-)
>
> Eric
>
>

I see you already figured out how to get the source; but instead of
building the package, you can simply run:

cd path/to/lintian/cone/
LINTIAN_ROOT="" frontend/lintian [options] <pkg>

Vastly faster than the waiting for the entire test suite.

~Niels


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DEB7AE8.6050902@thykier.net">http://lists.debian.org/4DEB7AE8.6050902@thykier.net
 
Old 06-05-2011, 01:25 PM
Eric Lavarde
 
Default Lintian Override for OSGi classpath in Freeplane?

On 05/06/11 14:47, Niels Thykier wrote:

LINTIAN_ROOT="" frontend/lintian



$ LINTIAN_ROOT="" frontend/lintian -vi
/home/ericl/ALIOTH/build-area/freeplane_1.1.3-1_i386.changes

N: Setting up lab in /tmp/xpbW7820tM ...
N: ----
N: Processing changes file freeplane_1.1.3-1_i386 (version 1.1.3-1) ...
N: ----
N: Processing source package freeplane (version 1.1.3-1) ...
N: ----
N: Processing binary package libjortho-freeplane-java (version 1.1.3-1) ...
N: ----
N: Processing binary package freeplane (version 1.1.3-1) ...
W: freeplane: classpath-contains-relative-path
usr/share/freeplane/core/org.freeplane.core/lib/freeplaneeditor.jar: ../

N:
N: The classpath listed in the jar file refers to a potential missing jar
N: file. This could be the remnants of a build-time classpath that
are not

N: relevant for a JAR bundled in a Debian package.
N:
N: Alternatively, the classpath may be correct, but the package is
lacking

N: a jar file or a symlink to it.
N:
N: Note, Lintian assumes that all (relative) classpaths pointing to
N: /usr/share/java/ (but not subdirs thereof) are satisfied by
dependencies

N: as long as there is at least one strong libX-java dependency.
N:
N: Severity: normal, Certainty: possible
N:
N: Removing /tmp/xpbW7820tM ...

I've uploaded a new version of Freeplane to mentors (attached email, I
need a sponsor - WINK!; also checked in SVN), with changelog entry:


* Fix lintian warnings (description, library dependency on jre),
'relative classpath in manifest' ignored until lintian clarified.
 

Thread Tools




All times are GMT. The time now is 09:34 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org