On 13 December 2010 19:06, Eric Evans <eev...@rackspace.com> wrote: > On Mon, 2010-12-13 at 17:12 +0000, Stephen Connolly wrote: >> OK, on that basis the beast way to go is to push the same jars that >> are being redistributed into central under the o.a.c groupId... it >> amounts to the same as you are doing currently... but I may look into >> putting in place some automation to consolidate duplicate jars > > Can you elaborate more on this? Are you saying that we'd continue to > maintain the contents of lib/ in svn, and publish the jars to our > groupId in the repo at release time? Or, do you mean that we'd maintain > the canonical list jars in the repo and retrieve them at build time? >
What I mean is that we'd use ivy (or maven ant tasks if you are not opposed to it... but it doesn't really matter which) to pull down what we think is the matching version in SVN, and then compare the md5 or sha1 of the lib version with the repo version. If the checksum matches, then we point the pom at the repo version, otherwise we redist the SVN lib version in o.a.c... so as long as you keep pulling down versions that are in central the pom will correctly point to the repo version (without munging up the GAV coordinates) and the Maven/Gradle/Ivy/Grapes world will be happy. > -- > Eric Evans > eev...@rackspace.com > >
