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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f213296.50...@nikhef.nl
