The quilt / maven-helper dance

In order to achieve a successful build, it is sometimes it is necessary to modify a pom.xml file in a way which cannot be achieved purely through using mh_patchpoms. In these cases, one falls back on using quilt as the standard mechanism for patching an upstream source. See for example:

https://anonscm.debian.org/cgit/pkg-java/dropwizard-metrics.git/tree/debian/patches/drop-graphite-rabbitmq-support.patch?id=f2a998aeeaa7e4e3f209a37cc79fe0a168281561

However, this now means that there are two mechanisms modifying the same file, quilt and mh_(un)patchpom, which can be confusing.

In particular, I would normally expect running debuild followed by debclean in an unpacked source package to build the package and then return the package to its original state. However, this is not what happens at the moment:

Sequence during debuild:

dpkg-source --before-build dropwizard-metrics
(This applies the quilt patch to the original pom.xml)
mh_unpatchpoms -plibdropwizard-metrics-java
(This shouldn't do anything, as there are no mh patched poms at this stage)
mh_patchpoms -plibdropwizard-metrics-java --debian-build --keep-pom-version --maven-repo=/home/mans0954/src/pkg-java/dropwizard-metrics/debian/maven-repo
(This copies the quilt patched pom.xml to pom.xml.save and then writes a mh modified pom to pom.xml)
dpkg-source --after-build dropwizard-metrics
(This then attempts to unapply the quilt patch from the mh modified pom.xml, but not pom.xml.save.)

Sequence during debclean

mh_unpatchpoms -plibdropwizard-metrics-java
(This moves pom.xml.save to pom.xml, so that pom.xml no longer has the mh modifications, but still has the quilt patch applied. Running "quilt pop -a" has no effect as quilt has previously unapplied the patch to the mh-modified pom.xml which has just been over-written))

I've found some workarounds:

1) Call debuild with the -tc option, which causes dpkg-buildpackage to invoke the clean target in debian/rules after the build but before the unpatching
2) Adding --no-unapply-patches to debian/source/local-options which stops dpkg-source from unapplying the patches. The package can then be cleaned with debclean && quilt pop -a

I'm wondering if there's a better way of fixing this though?

One possibility which occurred to me was to add an optional --post-transform=<path> argument to mh_patchpom to allow an arbitrary XSLT transform to be applied to pom.xml. This would then avoid the need to use quilt to patch pom files.

Another approach might be to not run mh_patchpoms during the build, but for the package maintainer to use it to generate patches in debian/patches which could be applied/unapplied at build time by quilt along with any other patches required.

Or am I just overthinking this? Any thoughts?

Christopher