On 15/05/13 08:31, Thomas Koch wrote: > On Tuesday, May 14, 2013 10:18:47 PM Daniel Pocock wrote: >> On 12/05/13 21:11, Bernd Zeimetz wrote: >>> On 05/11/2013 10:12 AM, Daniel Pocock wrote: >>>> On 11/05/13 04:35, Paul Wise wrote: >>>>> I think you want to discuss this on the debian-java list instead. > I'm working on the debian-repo-helper and debian-maven-helper packages to > improve our packaging workflow. You're very welcome to help. But it's not as > simple as you suggest. > > But please keep this discussion on debian-java. I don't feel comfortable to > bother everybody with the crap that we've to deal with in debian-java. >
There is a non-Java part of this problem too, but I'm quite happy to discuss the Java aspects through debian-java as this is my most pressing use-case I found maven-repo-helper and maven-debian-helper but not debian-repo-helper and debian-maven-helper, I think you were referring to the former? One particular point for me is tooling or fully automating the low-level parts of the process on a best-efforts basis: - automatically finding upstream source tarballs or repositories and working out how to find tags (if they exist) - scanning upstream source to identify risk items (e.g. binary JARs containing dependencies, build tools or compiled JNI code) - where necessary, creating repackaged upstream tarballs (specifically, creating git clones of the upstream and then creating a branch for generating the repackaged upstream) - scanning the upstream source to work out how to build it (e.g. does it just build with `ant' or `mvn') - generating a Jenkins config XML to build the project from (repackaged) source and deploy it to a local Maven repo Ideally, this tooling would be generic enough to work with non-Maven and even non-Java artifacts, e.g. to obtain an autotools project or R package and work out how to build it and start tracking it in a local Jenkins installation I realise this won't work for every upstream - but building such automation would allow us to simply scan the whole Maven repository and generate some kind of `heat map' to show which dependency graphs build easily because everything has a pom.xml or build.xml, with a red light for any part of a dependency graph that fails to build. -- 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/51a34fcc.5000...@pocock.com.au
