The fact that you're referring to "the local Git repository" (that's "the", not "a") sets off some warning bells for me. That terminology makes me suspect that you don't quite understand what Git is or how it works. And you really, *really* don't want source control sitting on top of your local Ivy cache — that'll just be a headache, especially when you decide to clear your cache or when updates happen.
When you check out a Git project, you end up with files checked out onto the file system, just like any source control. So if that folder looks like an Ivy repository, you should be able to use it just by pointing a "mavenRepo" to it using a file:// URL. I'm not sure you really want Gradle pulling from remote Git repositories (even the default upstream), because you'll end up with merge issues and the like which are difficult to handle programmatically. When projects do that obnoxious re-release thing, then blow away the entry in your Ivy cache. Once that's done, you'll pull against a new version. But they really shouldn't do that. Another option is to check out the project into your project as a subproject, and to map it as a submodule using Git. I do this for Clojure for my programming language, since I want to be living always with the newest and greatest code. Then you can have Gradle build the other project and supply it as a dependency. ~~ Robert. On Fri, Jun 24, 2011 at 1:47 AM, Mike Mills <[email protected]> wrote: > Does anyone have any information on how to use Git as a local ivy > repository or cache? > > I would like to be able to use Git as a local repository, and if the > artefact is not there, then go to the next resolver as normal. > > However, I would like it so that if an artefact is retrieved elsewhere > that the artefact is added into the local Git repository. > > This is akin to replacing the Gradle cache file with a Git repository > with automatic commits to Git for NEW artefacts or version, and an > error or confirmation should a REPLACEMENT jar be available for a > particular version of a jar already downloaded. > > The advantage of this setup would be that any changes to artefacts > would be tracked should things change and the confirmation would allow > the user to be aware that things might break due to the replacement > artefact. > > I have had on a couple of occasions externally sourced maven > dependencies that have just changed. Ie version 1.1 has been > re-released, different jar contents but reusing the same jar version. > > In maven this is a real issue, as anyone who has the old version in > their repository builds against one version of the dependency, and new > developers to the project get a different version. > > Is git a good way to achieve this and can it be integrated into gradle? > > Regards, > > Mike > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
