This is the kind of problem that Artifactory solves for you.
On Jun 24, 2011, at 5:31 AM, Robert Fischer wrote:
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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
