Re: Debianizing the Java world?
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.
Reply to: