Re: Review of fairsim, libjtransforms-java and libjlargearray-java
On 3 October 2017 at 18:12, Markus Koschany <apo@debian.org> wrote:
> Am 03.10.2017 um 17:30 schrieb Carnë Draug:
>> On 2 October 2017 at 00:21, Markus Koschany <apo@debian.org> wrote:
>>> [...]
>>> You don't have to add the classpath to the library. The Lintian check
>>> that warned about this issue has recently been removed.
>>
>> Without the classpath, then users of the jar files need to figure out
>> the dependencies themselves which does not work. As someone that
>> routinely uses java libraries via Python and Octave, I find it
>> essential.
>
> It really depends on the build system. Since this is a Maven project
> dependencies are declared in pom.xml files. What you are referring to is
> Debian's way of installing jar files into /usr/share/java. This is meant
> for build systems like Ant where you can easily add a symlink to your
> package and reference the versionless jar file. That's fine if you want
> to support this use case but it is not essential to get another package
> working and it might even introduce unwanted side effects like [1].
I don't understand why the build system used by a project should
affect the end user of said project.
I am also not referring to the Debian's way of installing jar files
into /usr/share/java. I am saying that users of library X in Debian
should not need to figure out which are the dependencies of library X
and add it to the java classpath themselves. For example, to make use
of libfairsim in Python without having the classpath defined in the
manifest file, a user will have to add the JlargeArrays, JTransforms,
and commons-math3 jar files to the classpath. As if that was not bad
enough, the user will need to figure out himself this list of
dependencies.
This is not limited to use java libraries in Python. It also happens
in Octave. And it is also an issue in ImageJ which is a Java
application where plugins are the jar files in its plugins directory.
That's simply not usable.
Maybe Class-Path is not an ideal solution but is there an alternative
to it?
>>> If you do it and
>>> use jh_classpath or the *.classpath file then you must specify the
>>> absolute path to the libraries otherwise they won't be found.
>>
>> Not true. The path can be relative to the directory of the jar file
>> that contains the manifest file.
>
> Let me rephrase this. It is possible but bad practice. Don't assume that
> your jar file is always in the same directory as your dependencies. The
> only way to ensure that is to use an absolute path.
>
Why is that bad practice?
Is that in case another package uses a symlink to the jar file and
uses it instead? My experience is that even when there's symlinks
involved, the Class-Path will be relative to directory of the real
file. Even if the other packages make symlinks to the jar, it will
still find the dependencies.
Or is that to cover the case the user copies the file and uses it
somewhere else?
>>> I also suggest to remove the --has-package-version flag from the *.poms
>>> files. There was a recent change in maven-debian-helper that
>>> automatically adds a versioned dependency to reverse-dependencies if one
>>> of their build-dependencies uses this flag. In my opinion in most cases
>>> this is too strict and not what you probably wanted.
>>>
>>> Regarding your failing patch I'm not sure. It doesn't sound like it is
>>> Java specific. You can send me your patch and I can take a look though.
>>>
>>
>> Here is the patch [1]. When I build with this patch, quilt will make
>> a copy of the original org.fairsim.fiji.FairSim_ImageJplugin package
>> in `.pc/set-git-build-id.patch/org/fairsim/fiji/FairSim_ImageJplugin.java`
>> This causes a duplicate class error because both the original and copy
>> are found.
>
> I can reproduce your issue. This is related to upstream's unusual choice
> of options in the pom.xml file. First of all I'm not sure why he won't
> simply stick to the default Maven directory layout (src/main/...).
Because he doesn't use or like maven. It's there only so that other
people can make use of it but he uses the Makefile for himself. I can
also understand why one would find the default maven directory layout
too deep.
> This
> would solve your problem immediately. The issue here is that he uses
> <sourceDirectory>./</sourceDirectory> which tells Maven to look into the
> root of your build directory and then it detects the patched class in
> the ~/.pc directory and the original class under org and fails.
>
> I would try to fix the build system (the pom.xml) but I don't have a
> patch at hand at the moment. Perhaps someone else on the list knows a
> better solution.
>
I have tried to change the build system already but I can't figure out
the right maven magic to make it look only inside ".org" either. I
think it may have to do with how debian-maven-helper is used. Note
how I had to manually remove a java file from the source tree in
`rules` [2] even though `pom.xml` should clearly exclude it [3].
Carnë
[2] https://github.com/carandraug/debian-fairsim/blob/master/debian/rules#L6
[3] https://github.com/carandraug/debian-fairsim/blob/master/pom.xml#L123
Reply to: