Hello,

I'm new to maven-debian-helper and am trying to package
jackson-modules-java8 [0], as part of a larger project to package
mssql-jdbc.

[0]: https://github.com/FasterXML/jackson-modules-java8

I've got my dev env with m-d-h, along with (I believe) all the relevant
java packages for the build-deps including libjackson2-core-java. I try
running mh_make as follows:

$ mh_make --package=jackson-modules-java8 \
--bin-package=libjackson2-modules-java8-java \
--javadoc=false --run-tests=false

After mostly accepting the defaults and ignoring some irrelevant plugins
and test deps, I end up with the following error:

[FATAL] Non-resolvable parent POM for com.fasterxml.jackson.module:jackson-modules-java8:2.14.2: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact com.fasterxml.jackson:jackson-base:pom:2.14.2 has not been
downloaded from it before. and 'parent.relativePath' points at wrong local POM @ line 8, column 10

I then manually hack the version of the jackson-base parent in the rootdir pom.xml to use the debian version as follows:

diff --git a/pom.xml b/pom.xml
index 8c55a38..0e99618 100644
--- a/pom.xml
+++ b/pom.xml
@@ -3,7 +3,7 @@
<parent>
<groupId>com.fasterxml.jackson</groupId>
<artifactId>jackson-base</artifactId>
- <version>2.14.2</version>
+ <version>debian</version>
</parent>
<groupId>com.fasterxml.jackson.module</groupId>
<artifactId>jackson-modules-java8</artifactId>


Re-running mh_make (after cleaning up the failed run) then gives me:

[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs: [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ com.fasterxml:oss-parent:debian, /usr/share/maven-repo/com/fasterxml/oss-parent/debian/oss-parent-debian.pom, line 173, column 12
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.fasterxml:oss-parent:debian, /usr/share/maven-repo/com/fasterxml/oss-parent/debian/oss-parent-debian.pom, line 217, column 12
[WARNING] 'build.plugins.plugin.ve

Le 2023-02-08 05:47, Joe Nahmias a écrit :

[ERROR] Unresolveable build extension: Error resolving version for
plugin 'org.apache.felix:maven-bundle-plugin' from the repositories
[local (/usr/share/maven-repo), central (https://repo.maven.apache.org/maven2)]: Plugin not found in any
plugin repository @

Is this a bug in libjackson2-core-java (which provides oss-parent) for stripping the version tags in the plugin section (they are present
upstream and in the source) or am I misusing mh_make and/or maven-debian-helper in some non-obvious (to me) way?

Hi Joe,

You can try changing the packaging type from bundle to jar, or ignore
the parent pom, just to get the initial run of mh_make to complete
without error.

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Feb 08, 2023 at 08:51:48AM +0100, Emmanuel Bourg wrote:

Le 2023-02-08 05:47, Joe Nahmias a �crit�:

[ERROR] Unresolveable build extension: Error resolving version for
plugin 'org.apache.felix:maven-bundle-plugin' from the repositories
[local (/usr/share/maven-repo), central (https://repo.maven.apache.org/maven2)]: Plugin not found in any
plugin repository @

Is this a bug in libjackson2-core-java (which provides oss-parent) for stripping the version tags in the plugin section (they are present
upstream and in the source) or am I misusing mh_make and/or maven-debian-helper in some non-obvious (to me) way?

Hi Joe,

Hi Emmanuel,

You can try changing the packaging type from bundle to jar, or ignore
the parent pom, just to get the initial run of mh_make to complete
without error.

Alright, I've tried removing the parent sections from the root pom.xml.
Then, in the pom.xml within the module subdirs, I:

* removed the <parent> reference to the rootdir pom
* changed the packaging from bundle to jar
* added missing <version> and <groupId> tags

When I then run mh_make, I receive:

[ERROR] Error resolving version for plugin 'com.google.code.maven-replacer-plugin:replacer' from the repositories [local (/usr/share/maven-repo), central (https://repo.maven.apache.org/maven2)]: Plugin not found in any plugin repository -> [Help 1]

From the comments in the pom.xml, it seems this is used to generate the PackageVersion.java. Feels a bit wrong to rip this out too, but maybe it's

just necessary to get mh_make to complete and then I can put all these
things back for build. Is that the path I should be taking? Is this
normal?

It would be nice if there were a newer tutorial on using m-d-h using recent versions.

Emmanuel Bourg

--Joe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Feb 08, 2023 at 06:03:50PM -0500, Joe Nahmias wrote:

On Wed, Feb 08, 2023 at 08:51:48AM +0100, Emmanuel Bourg wrote:

Le 2023-02-08 05:47, Joe Nahmias a �crit�:

[ERROR] Unresolveable build extension: Error resolving version for
plugin 'org.apache.felix:maven-bundle-plugin' from the repositories [local (/usr/share/maven-repo), central (https://repo.maven.apache.org/maven2)]: Plugin not found in any
plugin repository @

Is this a bug in libjackson2-core-java (which provides oss-parent) for stripping the version tags in the plugin section (they are present upstream and in the source) or am I misusing mh_make and/or maven-debian-helper in some non-obvious (to me) way?

Hi Joe,

Hi Emmanuel,

You can try changing the packaging type from bundle to jar, or ignore
the parent pom, just to get the initial run of mh_make to complete
without error.

Alright, I've tried removing the parent sections from the root pom.xml.
Then, in the pom.xml within the module subdirs, I:

* removed the <parent> reference to the rootdir pom
* changed the packaging from bundle to jar
* added missing <version> and <groupId> tags

When I then run mh_make, I receive:

[ERROR] Error resolving version for plugin 'com.google.code.maven-replacer-plugin:replacer' from the repositories [local (/usr/share/maven-repo), central (https://repo.maven.apache.org/maven2)]: Plugin not found in any plugin repository -> [Help 1]

From the comments in the pom.xml, it seems this is used to generate the PackageVersion.java. Feels a bit wrong to rip this out too, but maybe it's just necessary to get mh_make to complete and then I can put all these
things back for build. Is that the path I should be taking? Is this
normal?

It turns out I missed adding the version of maven-replacer-plugin:replacer
in one of the poms. After fixing that and rerunning mh_make, I get a bit farther and then run into this:

[INFO] Building Jackson modules: Java 8 2.14.2 [1/4] [INFO] --------------------------------[ pom ]--------------------------------- [WARNING] The POM for com.fasterxml.jackson.core:jackson-annotations:jar:debian is missing, no dependency information available
[INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary for Jackson modules: Java 8 2.14.2:
[INFO]
[INFO] Jackson-module-parameter-names ..................... SKIPPED
[INFO] Jackson datatype: jdk8 ............................. SKIPPED
[INFO] Jackson datatype: JSR310 ........................... SKIPPED
[INFO] Jackson modules: Java 8 ............................ FAILURE [ 0.027 s] [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.115 s
[INFO] Finished at: 2023-02-08T23:09:31Z
[INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal on project jackson-datatype-jsr310: Could not resolve dependencies for project com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.14.2: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode
and the artifact com.fasterxml.jackson.core:jackson-annotations:jar:debian has not been downloaded from it before. -> [Help 1]

I see jackson-annotations comes from package libjackson2-annotations-java,
and indeed version 2.14.0-1 does not contain a debian symlink for /u/s/maven-repo [0]. Any more ideas?

[0]: https://packages.debian.org/sid/all/libjackson2-annotations-java/filelist

It would be nice if there were a newer tutorial on using m-d-h using recent versions.

Emmanuel Bourg

--Joe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 2023-02-09 00:24, Joe Nahmias a écrit :

I see jackson-annotations comes from package
libjackson2-annotations-java,
and indeed version 2.14.0-1 does not contain a debian symlink for /u/s/maven-repo [0]. Any more ideas?

You are probably missing a substitution rule for jackson-annotations:

com.fasterxml.jackson.core jackson-annotations * s/.*/2.x/ * *

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Feb 09, 2023 at 08:14:35AM +0100, Emmanuel Bourg wrote:

Le 2023-02-09 00:24, Joe Nahmias a �crit�:

I see jackson-annotations comes from package
libjackson2-annotations-java,
and indeed version 2.14.0-1 does not contain a debian symlink for /u/s/maven-repo [0]. Any more ideas?

You are probably missing a substitution rule for jackson-annotations:

com.fasterxml.jackson.core jackson-annotations * s/.*/2.x/ * *

Emmanuel Bourg

Thanks for all your help. I think I managed to figure this out finally.
I've put my repo on salsa here: https://salsa.debian.org/java-team/jackson-modules-java8

Anyone care to do a(n in-depth) review before I upload?

Thanks,
--Joe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 2023-02-09 19:39, Joe Nahmias a écrit :

Thanks for all your help. I think I managed to figure this out finally.
I've put my repo on salsa here: https://salsa.debian.org/java-team/jackson-modules-java8

Anyone care to do a(n in-depth) review before I upload?

Great! Here is my review:

- Don't build the -java-doc package, that's useless
- The Maven wrapper should be removed (mwn* and .mvn/wrapper/*)
- I'd use the default gbp branch layout (master/upstream/pristine-tar)
instead of the DEP 14 layout (debian/latest). Most Java packages
follow the gbp layout and it's important all packages remain
consistent.
- Drop the +ds suffix
- debian/changelog doesn't close an ITP bug
- Why declaring a Provides field on virtual packages? That's unusual

The content of the binary package is perfect. Nice trick in
debian/control
to reuse the same description, I didn't know that was possible.

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 9 Feb 2023, Emmanuel Bourg wrote:

The content of the binary package is perfect. Nice trick in debian/control
to reuse the same description, I didn't know that was possible.

These tricka usually lead to *really* awfully useless .changes files
though, unfortunately.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:  ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 10 Feb 2023, Vladimir Petko wrote:

Sorry for jumping into the discussion, but it looks like maven-helper
deploys
jar files slightly incorrectly.

I think this is an open bug where it’s still under discussion
whether to fix it there or change the java policy instead.

(Your eMail lines are much too long.)

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:  ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Sorry for jumping into the discussion, but it looks like maven-helper
deploys
jar files slightly incorrectly. It places <package>.jar in /usr/share/java
and
then creates a symlink <package>-<version>.jar to it, rather than place
<package>-<version>.jar and create a symlink <package>.jar. Would it be ok
to
submit a patch for that?

Best Regards,
Vladimir.

On Fri, Feb 10, 2023 at 11:07 AM Emmanuel Bourg <ebourg@apache.org> wrote:

Le 2023-02-09 19:39, Joe Nahmias a écrit :

Thanks for all your help. I think I managed to figure this out finally. I've put my repo on salsa here: https://salsa.debian.org/java-team/jackson-modules-java8

Anyone care to do a(n in-depth) review before I upload?

Great! Here is my review:

- Don't build the -java-doc package, that's useless
- The Maven wrapper should be removed (mwn* and .mvn/wrapper/*)
- I'd use the default gbp branch layout (master/upstream/pristine-tar)
instead of the DEP 14 layout (debian/latest). Most Java packages
follow the gbp layout and it's important all packages remain
consistent.
- Drop the +ds suffix
- debian/changelog doesn't close an ITP bug
- Why declaring a Provides field on virtual packages? That's unusual

The content of the binary package is perfect. Nice trick in
debian/control
to reuse the same description, I didn't know that was possible.

Emmanuel Bourg

<div dir="ltr">Hi, <br><br> Sorry for jumping into the discussion, but it looks like maven-helper deploys <br> jar files slightly incorrectly. It places &lt;package&gt;.jar in /usr/share/java and <br> then creates a symlink &lt;package&gt;-&lt;version&
gt;.jar to it, rather than place <br> &lt;package&gt;-&lt;version&gt;.jar and create a symlink &lt;package&gt;.jar. Would it be ok to <br> submit a patch for that?<br><br>Best Regards, <br> Vladimir.<br></div><br><div class="gmail_quote"><div dir="ltr"
class="gmail_attr">On Fri, Feb 10, 2023 at 11:07 AM Emmanuel Bourg &lt;<a href="mailto:ebourg@apache.org">ebourg@apache.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);
padding-left:1ex">Le 2023-02-09 19:39, Joe Nahmias a écrit :<br>

&gt; Thanks for all your help. I think I managed to figure this out finally.<br>
&gt; I&#39;ve put my repo on salsa here:<br>
&gt; <a href="https://salsa.debian.org/java-team/jackson-modules-java8" rel="noreferrer" target="_blank">https://salsa.debian.org/java-team/jackson-modules-java8</a><br>
&gt; <br>
&gt; Anyone care to do a(n in-depth) review before I upload?<br>

Great! Here is my review:<br>

- Don&#39;t build the -java-doc package, that&#39;s useless<br>
- The Maven wrapper should be removed (mwn* and .mvn/wrapper/*)<br>
- I&#39;d use the default gbp branch layout (master/upstream/pristine-tar)<br>    instead of the DEP 14 layout (debian/latest). Most Java packages<br>
   follow the gbp layout and it&#39;s important all packages remain <br> consistent.<br>
- Drop the +ds suffix<br>
- debian/changelog doesn&#39;t close an ITP bug<br>
- Why declaring a Provides field on virtual packages? That&#39;s unusual<br>

The content of the binary package is perfect. Nice trick in <br> debian/control<br>
to reuse the same description, I didn&#39;t know that was possible.<br>

Emmanuel Bourg<br>

</blockquote></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Feb 09, 2023 at 11:07:14PM +0100, Emmanuel Bourg wrote:

Le 2023-02-09 19:39, Joe Nahmias a �crit�:

Thanks for all your help. I think I managed to figure this out finally. I've put my repo on salsa here: https://salsa.debian.org/java-team/jackson-modules-java8

Anyone care to do a(n in-depth) review before I upload?

Great! Here is my review:

- Don't build the -java-doc package, that's useless

Um, why do you say it's useless?

- The Maven wrapper should be removed (mwn* and .mvn/wrapper/*)

Yeah, I thought about that only after I did the repack...

- I'd use the default gbp branch layout (master/upstream/pristine-tar)
instead of the DEP 14 layout (debian/latest). Most Java packages
follow the gbp layout and it's important all packages remain consistent.

ACK. That's an easy fix

- Drop the +ds suffix

Why? Isn't that traditionally used to show a repack?

- debian/changelog doesn't close an ITP bug

Yeah, I never opened one.

- Why declaring a Provides field on virtual packages? That's unusual

Okay, I was thinking it would help discoverability, but I can certainly
drop it.

The content of the binary package is perfect. Nice trick in debian/control
to reuse the same description, I didn't know that was possible.

Thanks, I only learned of it a few months ago.

Emmanuel Bourg

Much appreciated,
--Joe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 2023-02-10 01:50, Joe Nahmias a écrit :

- Don't build the -java-doc package, that's useless

Um, why do you say it's useless?

Because with every new Java release we keep getting new javadoc issues
breaking the builds and violating the Debian policies. Considering that
almost nobody use these packages it's not worth the time we're investing
in maintaining them. So the current trend is rather to remove them.

- Drop the +ds suffix

Why? Isn't that traditionally used to show a repack?

I have a preference for clean version numbers. The suffix is useful
if a version was already packaged and needs to be modified afterward
because unwanted files were included by mistake.

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 10 Feb 2023, Emmanuel Bourg wrote:

- Drop the +ds suffix

Why? Isn't that traditionally used to show a repack?

I have a preference for clean version numbers. The suffix is useful
if a version was already packaged and needs to be modified afterward
because unwanted files were included by mistake.

DevRef §6.7.8.2 indicates that using such a suffix for *all* repacked
origtgz is better.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:  ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 2023-02-10 15:01, Thorsten Glaser a écrit :

DevRef §6.7.8.2 indicates that using such a suffix for *all* repacked origtgz is better.

Almost all our packages are repacked, that's pointless and brings
no useful information.

https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#repackaged-upstream-source

"may use packagename-upstream-version+dfsg (or any other suffix which is
added to the tarball name) as the name of the top-level directory in its tarball. This makes it possible to distinguish pristine tarballs from repackaged ones."

The 'may' requirement for the suffix is very weak. The Lintian repackaged-source-not-advertised warning should be downgraded
to pedantic.

Our time is limited, let's focus on important things.

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)