maven-debian-helper: porting to dh(1)?

[Ludovic Claude]

Hello Steve,

Thanks for starting this task. You save me here, as my Perl skills are
next to zero. To answer to your questions, I would say:

- dh_auto_test could run mvn test, but this doesn't looks really needed
as a standard Maven build using package or install as target will launch
the unit tests unless they have been disabled. I would favour making
dh_auto_test a noop.

- dh_auto_build (and maven.mk for that matter) would benefit from using
install as the default target, as this fixes problems when building some
complex projects, and don't have any bad side effect. The only minus is
that the build uses slightly more time and space.

- the custom classpath using DEB_JARS or whatever you want to name it
sounds unecessary and bad practice as Maven takes care of all classpath
issues. You're allowing packagers to play with the internals of Maven,
and while I added this DEB_JARS to maven.mk, it's not a good idea to
keep it for dh. Anyway (and fortunately), nobody seems to use it.

- The double invocation of classworlds.jar actually launches Maven twice
- with different targets. We can easily optimize things here and launch
Maven only once, but with several targets, for example 'install
javadoc:jar'. The -Ddebian.package argument doesn't seem useful here.

- mh_patchpoms and mh_unpatchpoms can be improved to scan the list of
packages and find the *.poms files that they need in order to patch all
used POM files. I can copy the code already present in mh_install, it
will require a new release of maven-repo-helper.

- mvn-debian can be more actively maintained, I need to see how exactly
we can use it in your dh script.

Ludovic


On 08/01/2012 04:50, Steve Langasek wrote:
> Hi folks,
> 
> The wiki page at http://wiki.debian.org/Java/MavenBuilder mentions that
> supporting dh(1) is on the todo list.  As getting rid of cdbs interests me,
> I took a stab at implementing this.  The result is attached.
> 
> With this on the system, a maven-using package can have a dh(1) debian/rules
> that looks like this (taken from activemq):
> 
> #!/usr/bin/make -f
> 
> %:
> 	dh $@ --buildsystem=maven
> 
> override_dh_auto_build:
> 	dh_auto_build -- install
> 
> override_dh_install:
> 	dh_install
> 	chmod 644 debian/activemq/etc/activemq/instances-available/main/log4j.properties
> 	chmod 644 debian/activemq/usr/share/doc/activemq/examples/conf/log4j.properties
> 	chmod 644 debian/activemq/usr/share/activemq/README.txt
> 
> get-orig-source:
> 	uscan --download-version $(DEB_UPSTREAM_VERSION) --force-download --rename
> 
> 
> There are a few things that I feel are still moderately un-dh-like about
> this system, however, and I wonder if anyone here has ideas about how to
> improve it.
> 
>  - dh_auto_test isn't usable with this build system, because there is
>    evidently no standard 'check' target.  Is there some way that the
>    existence of a suitable target could be detected at build time?  (As a
>    fallback, we could make dh_auto_test a no-op except when overridden and
>    an extra argument has been passed for the target.)
> 
>  - Likewise, the only target supported by the build system is 'package', and
>    if the build system uses another, this must be passed as an argument to
>    dh_auto_build (see above).  Torsten assures me that 'package' is the
>    standard target and everything else is non-standard, but in my
>    unscientific examination of packages so far, 'install' seems to be a
>    fairly common alternative.
> 
>  - Extending the classpath for maven is done using a DEB_JARS envvar.  This
>    is rather un-dh; it also has weird semantics (inherited from the cdbs
>    class) in that it takes jar names in various formats and tries to search
>    the system for them.  At the very least, the variable name should
>    probably be changed for dh; DEB_ as a prefix for variables defined within
>    debian/rules is a cdbs-ism.  Would MAVEN_JARS be ok here?
> 
>  - The double invocation of classworlds.jar, once for the main package and
>    once for the docs package, is a bit awkward, and feeds into some of the
>    problems above.  For instance, since there's only one invocation of
>    dh_auto_build, you can't easily specify extra/alternative arguments that
>    you want to have passed for docs building but not for building of the
>    main package.  (BTW, does anyone know why the CDBS rules pass
>    -Ddebian.package when building docs, but not when building the main
>    package?)
> 
>  - The build system has to know the names of the binary packages its
>    building for.  This is certainly unusual, since dh_auto_build means
>    "build the upstream code", dh_auto_install means "install the upstream
>    software relative to a target directory", and only dh_install is used to
>    split the software into component binary packages.  In this case,
>    however, we have to know the name of the binary package we're acting on
>    to even call mh_patchpoms.  I don't see any way around this, but the net
>    effect is that dh_auto_* always have to be called in such a way that the
>    main java package is the first package it's acting on - either by being
>    listed first in debian/control, or by being passed as a -p option.
> 
>  - Above all, this build system does *not* degrade gracefully.  Degrading
>    gracefully is one of the most important design criteria of dh(1); if
>    dh_auto_build doesn't do what a package needs, that's not supposed to be
>    a problem, just override it and call the upstream target by hand.  But
>    with maven-debian-helper, that's difficult to do:  far from just being
>    able to call 'make', we have to call 'java -noverify -cp [...]
>    -Dclasswords.conf= [...]'.  I think it would be a very good idea to
>    encapsulate this commandline in some sort of standard wrapper, which
>    could then be invoked both by dh_auto_build and by a package's override
>    rule when needed.  Something like the 'mvn-debian' command - except that
>    mvn-debian is explicitly marked as "not supported" by the maintainers...
>    :)  Is that something that could be changed?
> 
> I look forward to hearing your thoughts on these questions!
> 
> 
> 
> 
> __
> This is the maintainer address of Debian's Java team
> <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use
> debian-java at lists.debian.org for discussions and questions.