Frustration with trying to build Debian packages from Maven-based sources
Hi,
what follows is a somewhat rant-y account of the things that can go
wrong when someone who is experienced in Debian packaging (but rather
new to this Java thing) tries to prepare pacakges that are built using
Maven:
Initially, all I wanted to do was to build a proper Debian package for
ElasticSearch (#660826). It turns out that some needed
build-dependencies are not in Debian yet, so I start with version 2 of
jackson-core by downloading the jackson-core-2.1.4... This shouldn't be
too hard, right? After all, the maven build tool is widely used -- and
one would assume that this is the case because it makes it easy for
developer to get things done.
Normally, I would start off with dh_make (or dh-make-perl for modules
from CPAN). dh_make doesn't do anything useful, so let's look for
specific alternatives.
I found that mh_make (maven-debain-helper) and jh_makepkg (javahelper)
may be able to recognize maven as the build system and generate a
debian/ directory that might serve as a starting point. (Is there a
third alternative?)
jh_makepkg generates some boilerplate templates that are almost but not
completely different from what dh_make provides. The debian/rules file
uses a program called mvn-debian for the build and clean targets. The
comments at the beginning of /usr/bin/mvn-debian give me serious doubts
whether I will want to use this at all:
,----
| This is an example script that allows running maven on the command
| line in a similar way as our cdbs snippets work. Production use is
| not supported by the maintainer of maven-debian-helper.
`----
My attempt at building the package fails in the compile stage, but the
build process is not even interrupted, so let's just forget jh_makepkg.
I wonder what the rationale for shipping mvn-debian in /usr/bin is when
it's not fit for general consumption.
mh_make asks a number of unnecessary questions (it should just assume
sane defaults for package, binary-package, run-tests, javadoc,
upstream-version), and wants to run apt-file using sudo (WTF?).
It then asks questions that read more like compiler errors (Why do I
need to know at this point what a POM is?):
,----
| In pom.xml:
| The parent POM cannot be found in the Maven repository for Debian. Ignore it?
| com.fasterxml:oss-parent:pom:4
| [y]/n >
`----
... and some that don't make much sense to me at all:
,----
| Version of com.fasterxml.jackson.core:jackson-core is 2.1.4
| Choose how it will be transformed:
| [1] - Replace all versions starting by 2. with 2.x
| 2 - Change the version to the symbolic 'debian' version
| 3 - Keep the version
| 4 - Custom rule
`----
I assume that this may have something to do with how Maven resolves
build-dependencies, but there is no documentation and at this point I'm
not desperate enough to look a the source code to find out the intent.
Finally, mh_make leaves me with a debian/ directory with a CDBS-based
debian/rules that also fails to compile the project -- at least the
build error is not ignored this time. Apparently, the compiler is given
the wrong options about Java compatibility, I should be able to fix
that... All in all, this looks more promising than the crap that
jh_makepkg produced.
Some debian/maven.* files have been generated. I assume that
maven.{ignore,cleanIgnore,published}Rules and maven.rules may also have
something to do with how Maven resolves build-dependencies, but, again,
since there is no documentation...
As I understand it, there seem to be a few assumptions coded into Maven
that are opposed to Debian's ways of doing things:
- From Maven's point of view, downloading arbitrary pieces of binary
from the net while building is acceptable. Our (Debian's) attempt at a
solution seems to consist of using a local repository
(/usr/share/maven-repo) and always running maven in offline-mode. I did
not find any documentation about this, but by reading the CDBS rules
that pointed to /etc/maven2/settings-debian.xml...
- From Maven's point of view, it seems acceptable to depend on fixed,
possibly old, unmaintained, versions of libraries. Our solution appears
to be some rewriting magic that I haven't looked further into yet.
- Maven also wants to be a packaging and deployment system
My general feeling is that mh_make may be trying to do the right things
to bridge this "cultural gap". Unfortunately, there is not even any good
description about the problem it tries to solve, let alone how it solves
them. Finding out about more about the magic that it uses to do so is
harder than it needs to be.
I don't mean to offend anyone here nor belittle hard work that has gone
into the mentioned tools, but can't we do better than this?
Cheers,
-Hilko
Reply to: