On 08/26/2014 04:27 AM, Daniel Pocock wrote: > > Many Maven upstreams have a <version> for each plugin and dependency in > pom.xml > > Maven seems to work with precise versions whereas Debian often uses > minimum version or a range constraint for more flexibility. > > libphonenumber upstream agreed to remove the version constraint from > pom.xml so it just uses the available plugin versions in > /usr/share/maven-repo > > However, now Maven gives a lot of warnings. Should they put the > constraint back in? Will maven-debian-helper still be able to build the > package even if Debian doesn't have the exact plugin versions specified > by an upstream in their pom.xml? > > upstream commented that the Maven warnings are particularly critical of > people who don't specify precise versions, e.g: > > "future Maven versions might no longer support building such malformed > projects."
Hi Daniel, Typically, instead of asking upstream to remove the version constraint, the Debian packaging will either relax the version - e.g. s/3.4/3.x/ - or replace the version with "debian" (when the library provides maven artifacts for a "debian" version. This allows upstream to specify the version that they have developed and tested with, but gives us the flexibility to so some mapping in the event that we don't track the specific point release, assuming of course that the API and ABIs match. Note that this doesn't work across the board, for example, there are some challenges within the maven build system itself w.r.t. plugins. However, for most packages that build-depend on maven, you should be able to do this mapping in debian/maven.rules and listing maven-repo-helper in your build-deps (maven-debian-helper will pull in m-r-h by default). For an example (picking one at random) you can look at mvel. Here, the mapping is from any version "3" of junit to 3.x, and from any version whatsoever of asm to 3.x: junit junit jar s/3\..*/3.x/ * asm asm jar s/.*/3.x/ * I hope that helps. Cheers, tony
signature.asc
Description: OpenPGP digital signature