One of the differences between "mh_resolve_dependencies" and "mh_shlibdeps" is that "mh_shlibdeps" uses Maven Resolver to resolve dependencies, thus being able to better handle POM elements like variable substitutions, ignores, and inheritance. Though it can't handle version ranges since Maven Resolver needs "maven-metadata.xml" for the task.
This program was supposed to fulfill a wishlist I proposed long ago [1]. All the reasons are explained there. I also remember ebourg mentioned that one drawback of "mh_resolve_dependencies" is that it won't work if the JARs are split into multiple binary packages.
Another subtle difference is that "mh_shlibdeps" examines the Maven artifacts directly instead of reading "<package>.poms" files.
For "jh_manifest" and "mh_genlaunchers", they are quite different as "jh_manifest" hardcodes classpaths into JARs but "mh_genlaunchers" puts them in launcher scripts. I personally don't favor putting classpaths into JARs since there is no way to tell the JVM to ignore it and use another classpath.
And I also don't want to integrate these tools into "maven-debian-helper" because the whole point was to make them available for both Gradle and Maven packages.
[1]: https://bugs.debian.org/844531
Markus Koschany 於 2018年02月18日 星期日 01:18 上午 寫道:
> Hi,
>
> Am 16.02.2018 um 15:47 schrieb 殷啟聰 | Kai-Chung Yan:
>> I wrote 2 Debhelper plugins for easing maintenance of packages with Maven artifacts. They are in a new package called "maven-repo-helper-extras" [1].
>>
>> "mh_shlibdeps" works just like "dh_shlibdeps". It examines the Maven artifacts installed by a package and generate "${maven:Depends}" in a "<package>.substvars" file.
> First of all thanks for trying something new and improving our tool chain!
>
> How is mh_shlibdeps different from our current approach in
> maven-debian-helper? I mean ${maven:Depends} already exists and works as
> expected, maven-debian-helper scans the pom.xml file and injects runtime
> dependencies into this substvar.
>
>> "mh_genlaunchers" generates a Java program launcher script based on a "<package>.maven-launchers" file. It has a syntax like:
>>
>> usr/bin/mh_shlibdeps org.debian.maven.Shlibdeps org.debian:maven-debian-utils:debian
>>
>> This file specifies the launcher location, main class name and the Maven artifact providing said main class.
>>
>> The reason why I invented a new project instead of adding them to "maven-repo-helper" is that I wanted to implement it using upstream code (e.g. maven-resolver [2]) and in pure Java (without shell script like "javahelper").
> mh_genlaunchers sounds like an alternative to jh_manifest. Maybe if we
> could integrate it into maven-debian-helper build-depending on
> javahelper would be unnecessary in this case?
>
> Regards,
>
> Markus
>
>
>
>
Attachment:
signature.asc
Description: OpenPGP digital signature