Re: issues with maven-{repo,debian}-helper
Hello Dennis,
There are lots of questions here, so I'll try to answer as best as I can.
On 23/01/2012 22:59, Dennis van Dok wrote:
> Hi,
>
> I'm new to Java packaging but I feel I'm already finding some edge cases
> that may need looking into by more experienced people; they may even be
> bugs.
>
> I'd like to share two issues that caused me some headache.
>
> The package I'm trying to build is called argus-pdp-pep-common, part of
> a larger set of packages called ARGUS that comprise a site central
> authorization framework used in science grids. Upstream uses maven, so
> I've used the maven.mk class in cdbs. Because javahelper has good
> support for installing Manifests I'm using that too.
>
As a general rule of thumb, if upstream uses Maven, then use
maven-debian-helper for the build. Combining javahelper and maven.mk
doesn't look like a good idea and creates more work.
maven-debian-helper doesn't yet produce jars with Class-Path as required
by the Debian Java policy, but it may get that support in the future, so
IMHO using javahelper is not required.
In your case, the layout of the project makes everything difficult (why
did upstream split the parent pom in its own repository?), so your
choice may turn out to be good.
> The issue is this: upstream decided to split of a large piece of common
> data off the pom.xml into a parent pom. Most importantly, the versions
> of all dependencies are listed in the parent, not in the main pom.
>
> The parent could be packaged on its own, but it hardly makes sense to do
> so, as it's very much private to the ARGUS system. I chose to put the
> parent pom in debian/parent/pom.xml. The <package>.pom file in debian/
> lists both:
>
> pom.xml
> debian/parent/pom.xml
>
> but this setup never worked. No matter what I tried, the mh_patchpoms
> script would always insert <version>debian</version> for every
> dependency in the pom, instead of using the correct versions in the
> parent pom. This caused some dependencies to fail.
>
> The solution was so simple I nearly pulled my hair out: by reversing the
> listing
>
> debian/parent/pom.xml
> pom.xml
>
Indeed, files are processed in the order they are listed, and Maven
needs to process the parent POM first (in order to get the list of
dependencies and their versions), then the pom for your module.
The layout of your project doesn't looks good for a Maven project. I
would expect to see something like:
pom.xml (parent pom)
|_ pep-java-common
|_ pom.xml
|_ src / main / java
Maybe you can try to build the tarball from the 2 SVN repositories,
using the multiple upstream tarball functionality of dpkg-source. See
http://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/
> Things started to work. The documentation about this isn't wrong, but
> it's also far from obvious[1].
>
> 1. http://wiki.debian.org/Java/MavenRepoHelper
>
There is up to date and more complete documentation included in the
maven-repo-helper package at
/usr/share/doc/maven-repo-helper/tutorial.html
maven-debian-helper doesn't have yet a good documentation, but there's a
wiki page for it:
http://wiki.debian.org/Java/MavenDebianHelper
Your package is also far from obvious, as it doesn't use the more common
style of grouping everything under one repository and creating a
multi-module build:
http://maven.apache.org/guides/getting-started/index.html#How_do_I_build_more_than_one_project_at_once
> The second issue has to do with mh_patchpoms. I patched the
> <relativePath> of the pom to point to debian/parent/pom. Upon building
> with dpkg-buildpackage, this (quilt) patch happens first, then the
> mh_patchpoms changes the pom.xml to debianize it. After the package is
> completely build, in the final step dpkg-source --after-build comes by
> to undo the quilt patch; but at this time, the pom.xml is still the
> debianized one and not the one that had the quilt patch (that one is
> pom.xml.save). So the build fails at last because the patch won't apply
> in reverse.
>
> The solution I found here was to include the following in debian/rules:
>
>
> binary/libpdp-pep-common-java::
> mh_unpatchpoms -plibpdp-pep-common-java
>
> I'm thinking that this should have been taken care of by maven.mk...
>
mh_patchpoms and quilt patches pushed by dpkg-buildpackage seem to
conflict. I remember seeing that once, but I have found a workaround by
removing the need to have a patch on the pom.xml file. Can you send me
your package sources and let me examine the issue?
> Sorry for the long post, but that's what we get with these technicalities!
>
Thanks for giving such good details and feedback,
Ludovic
Reply to: