Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.java > #9788 > unrolled thread

wanting to join the java team

Back to article view | Back to linux.debian.maint.java

Contents

  wanting to join the java team Carnë Draug <carandraug+dev@gmail.com> - 2017-07-10 16:50 +0200
    Re: wanting to join the java team Markus Koschany <apo@debian.org> - 2017-07-10 17:50 +0200
      Re: wanting to join the java team Carnë Draug <carandraug+dev@gmail.com> - 2017-07-11 19:00 +0200
        Re: wanting to join the java team Markus Koschany <apo@debian.org> - 2017-07-13 22:00 +0200
          Re: wanting to join the java team Thorsten Glaser <t.glaser@tarent.de> - 2017-07-14 10:00 +0200
          Re: wanting to join the java team Carnë Draug <carandraug+dev@gmail.com> - 2017-07-14 18:00 +0200
            Re: wanting to join the java team Markus Koschany <apo@debian.org> - 2017-07-14 20:20 +0200
              Re: wanting to join the java team Carnë Draug <carandraug+dev@gmail.com> - 2017-07-14 22:30 +0200
                Re: wanting to join the java team Markus Koschany <apo@debian.org> - 2017-07-16 23:50 +0200
                  Re: wanting to join the java team Carnë Draug <carandraug+dev@gmail.com> - 2017-07-27 18:00 +0200
                    Re: wanting to join the java team Markus Koschany <apo@debian.org> - 2017-07-27 18:00 +0200
                      Re: wanting to join the java team Carnë Draug <carandraug+dev@gmail.com> - 2017-07-29 17:00 +0200
                        Re: wanting to join the java team Markus Koschany <apo@debian.org> - 2017-07-29 17:10 +0200
                          Re: wanting to join the java team Carnë Draug <carandraug+dev@gmail.com> - 2017-09-28 13:50 +0200
                            Re: wanting to join the java team Markus Koschany <apo@debian.org> - 2017-09-28 18:00 +0200
                              Review of fairsim, libjtransforms-java and libjlargearray-java Markus Koschany <apo@debian.org> - 2017-10-02 01:30 +0200
                                Re: Review of fairsim, libjtransforms-java and libjlargearray-java Emmanuel Bourg <ebourg@apache.org> - 2017-10-02 23:00 +0200
                                  Re: Review of fairsim, libjtransforms-java and libjlargearray-java Markus Koschany <apo@debian.org> - 2017-10-03 19:40 +0200
                                Re: Review of fairsim, libjtransforms-java and libjlargearray-java Emmanuel Bourg <ebourg@apache.org> - 2017-10-02 23:20 +0200
                                  Re: Review of fairsim, libjtransforms-java and libjlargearray-java Markus Koschany <apo@debian.org> - 2017-10-02 23:50 +0200
                                Re: Review of fairsim, libjtransforms-java and libjlargearray-java Carnë Draug <carandraug+dev@gmail.com> - 2017-10-03 17:40 +0200
                                  Re: Review of fairsim, libjtransforms-java and libjlargearray-java Markus Koschany <apo@debian.org> - 2017-10-03 19:20 +0200
                                    Re: Review of fairsim, libjtransforms-java and libjlargearray-java Carnë Draug <carandraug+dev@gmail.com> - 2017-10-04 17:50 +0200
                                      Re: Review of fairsim, libjtransforms-java and libjlargearray-java Markus Koschany <apo@debian.org> - 2017-10-04 19:20 +0200
                                        Re: Review of fairsim, libjtransforms-java and libjlargearray-java Carnë Draug <carandraug+dev@gmail.com> - 2017-10-05 13:10 +0200
                                          Re: Review of fairsim, libjtransforms-java and libjlargearray-java Markus Koschany <apo@debian.org> - 2017-10-05 14:40 +0200

Page 2 of 2 — ← Prev page 1 [2]

#10057 — Re: Review of fairsim, libjtransforms-java and libjlargearray-java

On 2 October 2017 at 00:21, Markus Koschany <apo@debian.org> wrote:
> Hi,
>
> I think all three packages are in a good shape but there are some issues.
>
> Standards-Version is 4.1.1 now.
>
> I suggest to remove the -doc packages because I don't believe those
> libraries are significant enough to warrant the maintenance of
> additional documentation packages but I leave the decision to you. That
> would also simplify the packaging a little.

I actually like and use the docs packages so I'd rather keep them.

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

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

> you rarely need both javahelper and maven-debian-helper in one package.
> I believe maven-debian-helper would suffice here and you can remove the
> build-dependency on javahelper and the related substvars.

I thought that d/package-name.classpath file was used by jh_classpath
and that is provided by javahelper.  Or how can I set the classpath on
the manifest without it?

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

Thank you
Carnë

[1] https://github.com/carandraug/debian-fairsim/commit/ffe1cf94d174a2722a478372685b98900e977a76

[toc] | [prev] | [next] | [standalone]

#10059 — Re: Review of fairsim, libjtransforms-java and libjlargearray-java

[Multipart message — attachments visible in raw view] — view raw

Am 03.10.2017 um 17:30 schrieb Carnë Draug:
> On 2 October 2017 at 00:21, Markus Koschany <apo@debian.org> wrote:
>> Hi,
>>
>> I think all three packages are in a good shape but there are some issues.
>>
>> Standards-Version is 4.1.1 now.
>>
>> I suggest to remove the -doc packages because I don't believe those
>> libraries are significant enough to warrant the maintenance of
>> additional documentation packages but I leave the decision to you. That
>> would also simplify the packaging a little.
> 
> I actually like and use the docs packages so I'd rather keep them.

Fair enough.

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

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

>> you rarely need both javahelper and maven-debian-helper in one package.
>> I believe maven-debian-helper would suffice here and you can remove the
>> build-dependency on javahelper and the related substvars.
> 
> I thought that d/package-name.classpath file was used by jh_classpath
> and that is provided by javahelper.  Or how can I set the classpath on
> the manifest without it?

Indeed we use javahelper as a tool to modify the classpath in manifest
files. There are other ways but using jh_classpath or *.classpath is the
recommended and most like easiest way to achieve it. If you want to
support this you must depend on javahelper.

>> 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/...). 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.

Regards,

Markus

[1] https://lists.debian.org/debian-java/2017/09/msg00062.html

[toc] | [prev] | [next] | [standalone]

#10061 — 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

[toc] | [prev] | [next] | [standalone]

#10062 — Re: Review of fairsim, libjtransforms-java and libjlargearray-java

[Multipart message — attachments visible in raw view] — view raw

Am 04.10.2017 um 17:42 schrieb Carnë Draug:
> 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. 

[...]

Those libraries are Maven projects and they are intended to be used as
dependencies for other Maven projects by upstream. I can't find any hint
of support for other build systems in the original tarballs. What you
are doing is adding support for other use cases by installing the jar
files into /usr/share/java. That's absolutely fine and the historical
way how Java projects were initially packaged for Debian. For a pure
Maven project adding the Class-Path attribute to the manifest file would
be unnecessary because the files in /usr/share/java are not used by Maven.

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

Can you guarantee that your relative path is always unambiguous even if
you copy the jar file into another project or install the jar file into
a completely different directory? I have been working for the past five
years in this team and I can tell you a lot of things can go wrong when
it comes to class loading. It really helps if all packages behave
identical hence you will find many, many packages in our team that use
absolute paths when exporting the CLASSPATH variable or when modifying
the Class-Path attribute.

[...]
>>
>> 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.

That is not an excuse for writing bad pom files.

>  I can
> also understand why one would find the default maven directory layout
> too deep.

Actually the coherent and logical structure of Maven projects is one of
Maven's biggest strengths.

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

This is not an issue with maven-debian-helper because it simply invokes
Maven which rightfully complains about duplicated classes. The pom.xml
and the directory layout should be changed.

Markus

[toc] | [prev] | [next] | [standalone]

#10066 — Re: Review of fairsim, libjtransforms-java and libjlargearray-java

On 4 October 2017 at 18:17, Markus Koschany <apo@debian.org> wrote:
> Am 04.10.2017 um 17:42 schrieb Carnë Draug:
>> 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.
>
> [...]
>
> Those libraries are Maven projects and they are intended to be used as
> dependencies for other Maven projects by upstream.

I still don't understand the connection between the build system of a
project and how the end binary should be used afterwards.  These are
not Maven projects.  They are Java projects where maven was the build
system.  The build system should only affect how that project is
built, not how it is used by the end-user.

> I can't find any hint
> of support for other build systems in the original tarballs.

That's not what I am trying to do. The java library is already built.
I am only trying to configure it properly for usage in a Debian
system.  Both fairsim and JTransforms provide a jar file with all
dependencies bundled to be used so one can use them fine without
maven.

> What you
> are doing is adding support for other use cases by installing the jar
> files into /usr/share/java. That's absolutely fine and the historical
> way how Java projects were initially packaged for Debian. For a pure
> Maven project adding the Class-Path attribute to the manifest file would
> be unnecessary because the files in /usr/share/java are not used by Maven.
>>
>>>>> 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?
>
> Can you guarantee that your relative path is always unambiguous even if
> you copy the jar file into another project or install the jar file into
> a completely different directory?

If the file is not copied, which should not, then yes, it will
unambiguous.  Other Debian packages should create symlinks not copy
the file in which case the path will be resolved correctly.  Why
should Debian packages have to cover the case where a file is copied
somewhere else?

> I have been working for the past five
> years in this team and I can tell you a lot of things can go wrong when
> it comes to class loading. It really helps if all packages behave
> identical hence you will find many, many packages in our team that use
> absolute paths when exporting the CLASSPATH variable or when modifying
> the Class-Path attribute.
>

I believe you but I don't know what those situations are because I
never faced them and I am only starting with packaging java libraries.

My reasoning is that if the location of a jar file changes, it would
be more likely because the location for jar files in general changed.
So a relative path would continue to work while an absolute path would
break.  But I can set absolute paths no problem.

> [...]
>>>
>>> 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.
>
> That is not an excuse for writing bad pom files.

That is very unfair.  It is not a bad pom file because the project
builds fine.  Maven supports using alternative file structure and
that's what upstream is doing.  What is bad about it?  Seems fair to
me that a project should not have to worry with issues involving the
addition of foreign files to the tree.

>>> 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].
>
> This is not an issue with maven-debian-helper because it simply invokes
> Maven which rightfully complains about duplicated classes. The pom.xml
> and the directory layout should be changed.
>

A patch that moves all the files in 'org' to 'src/main/java/org' will
cause conflicts with each update.  Wouldn't be much less disruptive to
instead patch the pom.xml file to ignore a '.pc' directory?

Maven documentation suggests it is possible to exclude en entire
directory but for some reason the exclude options seem to be ignored
during the build.  Note that it even ignores the exclude options set
in the original pom.xml file which is why I think the issue is on
debian-maven-helper or what else is doing the compilation.

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

[toc] | [prev] | [next] | [standalone]

#10067 — Re: Review of fairsim, libjtransforms-java and libjlargearray-java

[Multipart message — attachments visible in raw view] — view raw

Am 05.10.2017 um 13:08 schrieb Carnë Draug:
[...]
> I still don't understand the connection between the build system of a
> project and how the end binary should be used afterwards.  These are
> not Maven projects.  They are Java projects where maven was the build
> system.  The build system should only affect how that project is
> built, not how it is used by the end-user.

Carnë I would really appreciate it if we could be more efficient with
this review. I have noticed this before but you seem to be in the habit
of questioning statements over and over again which are not
controversial at all and this will needlessly delay the review.

I only stated that your upstream packages are all Maven projects and
they are intended to be used in other Maven projects. If you take a look
at the README.md file of jlargearrays you can see for instance how
upstream thinks this library should be used. It is a Maven project and
that affects the end-user. Period.

>> I can't find any hint
>> of support for other build systems in the original tarballs.
> 
> That's not what I am trying to do. The java library is already built.
> I am only trying to configure it properly for usage in a Debian
> system.  Both fairsim and JTransforms provide a jar file with all
> dependencies bundled to be used so one can use them fine without
> maven.

Yes. Now take a look at my next two sentences.

> What you
>> are doing is adding support for other use cases by installing the jar
>> files into /usr/share/java. That's absolutely fine and the historical
>> way how Java projects were initially packaged for Debian.

Sounds familiar? My point was upstream obviously does not support other
build systems than Maven but you added support for it and that's great!

 For a pure
>> Maven project adding the Class-Path attribute to the manifest file would
>> be unnecessary because the files in /usr/share/java are not used by Maven.
>>>
>>>>>> 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?
>>
>> Can you guarantee that your relative path is always unambiguous even if
>> you copy the jar file into another project or install the jar file into
>> a completely different directory?
> 
> If the file is not copied, which should not, then yes, it will
> unambiguous.  Other Debian packages should create symlinks not copy
> the file in which case the path will be resolved correctly.  Why
> should Debian packages have to cover the case where a file is copied
> somewhere else?

Why should Debian not cover this use case?

>> I have been working for the past five
>> years in this team and I can tell you a lot of things can go wrong when
>> it comes to class loading. It really helps if all packages behave
>> identical hence you will find many, many packages in our team that use
>> absolute paths when exporting the CLASSPATH variable or when modifying
>> the Class-Path attribute.
>>
> 
> I believe you but I don't know what those situations are because I
> never faced them and I am only starting with packaging java libraries.

Here is a pro tip. If you are not a regular contributor to a project and
even a newcomer then it is usually advantageous to listen to what the
current members have to say and do not assume that everything they did
is totally wrong. Try to get the hang of packaging Java software for
Debian first. After you have studied, updated and fixed around 50
packages you will get the bigger picture and then it's time to criticize
them and to tell those fools how it should be done.

> My reasoning is that if the location of a jar file changes, it would
> be more likely because the location for jar files in general changed.
> So a relative path would continue to work while an absolute path would
> break.  But I can set absolute paths no problem.
> 
>> [...]
>>>>
>>>> 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.
>>
>> That is not an excuse for writing bad pom files.
> 
> That is very unfair.  It is not a bad pom file because the project
> builds fine.  Maven supports using alternative file structure and
> that's what upstream is doing.  What is bad about it?  Seems fair to
> me that a project should not have to worry with issues involving the
> addition of foreign files to the tree.

This thread is proof that this pom file is less than optimal. Use the
Maven conventions whenever you can, especially for smaller projects like
fairsim. This will make life for people like us tremendously easier. You
believe using an alternative file structure is a completely valid
solution? Absolutely! But then you must also figure out another way to
solve your problem.

>>>> 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].
>>
>> This is not an issue with maven-debian-helper because it simply invokes
>> Maven which rightfully complains about duplicated classes. The pom.xml
>> and the directory layout should be changed.
>>
> 
> A patch that moves all the files in 'org' to 'src/main/java/org' will
> cause conflicts with each update.  Wouldn't be much less disruptive to
> instead patch the pom.xml file to ignore a '.pc' directory?

Yes, that is a valid solution/workaround.

> Maven documentation suggests it is possible to exclude en entire
> directory but for some reason the exclude options seem to be ignored
> during the build.  Note that it even ignores the exclude options set
> in the original pom.xml file which is why I think the issue is on
> debian-maven-helper or what else is doing the compilation.

When I remove the override for dh_auto_build I can't find any trace of
the JTransformsForkConnector class. Seems to work as intended unless I
missed something else.


Steps to get your packages uploaded:

1. Fix the Standards-Version
2. Use absolute paths
3. (optional) apply your patch for fairsim and fix the build failure as
you see fit*


* Must be Policy compliant though

Thanks,

Markus

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.maint.java

csiph-web