FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Java

 
 
LinkBack Thread Tools
 
Old 01-23-2012, 08:59 PM
Dennis van Dok
 
Default issues with maven-{repo,debian}-helper

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.

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

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

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...

Sorry for the long post, but that's what we get with these technicalities!

Cheers,

Dennis

--
D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.biggrid.nl
Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F1DD82F.9020203@nikhef.nl">http://lists.debian.org/4F1DD82F.9020203@nikhef.nl
 
Old 01-25-2012, 10:30 PM
Ludovic Claude
 
Default 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


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F209095.8000803@laposte.net">http://lists.debian.org/4F209095.8000803@laposte.net
 
Old 01-26-2012, 10:01 AM
Dennis van Dok
 
Default issues with maven-{repo,debian}-helper

Op 26-01-12 00:30, Ludovic Claude schreef:
> Hello Dennis,
>
> There are lots of questions here, so I'll try to answer as best as I can.

Hi Ludovic,

thanks for your reply and kudos for your excellent work!

[...]

>> 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.

OK, that was precisely why I used it. If the next m-d-helper takes care
of it, I probably don't need it anymore.

> 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.

Upstream does integrate the parent pom through SVN externals. And as it
turns out, after I wrote this e-mail I hit another problem; if I don't
install the parent pom and use --no-parent on the components, they lose
the version information for their dependencies; building against these
packages failed because of this. This led me to introduce the parent as
a separate package anyway.

[...]

> 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/

I guess; but the <relativePath> element works fine IMHO.

[...]

> 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

I'm not a Maven expert at all; this is something that upstream will have
to explain. But I guess we're trying to keep modules as separate
packages, right? Are you suggesting to merge them into a single source
package and have it produce multiple binary packages?

> 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?

https://github.com/dvandok/argus-pdp-pep-common

The patch I need has to do with dependencies that are in Debian, but not
yet as Maven repositories. I've filed bugs about that but in the
meantime I needed to switch these dependencies to system scope.


Cheers,

Dennis
--
D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.biggrid.nl
Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F213296.50308@nikhef.nl">http://lists.debian.org/4F213296.50308@nikhef.nl
 

Thread Tools




All times are GMT. The time now is 03:26 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org