[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: