On Apr 10, 2009, at 9:08 AM, PSpeed wrote:
hdockter wrote:
On Oct 5, 2008, at 9:21 PM, Peter Niederwieser wrote:
Russel Winder-4 wrote:
The problem here is though that if the Maven repository is being
used
then it should be used as the user believes the Maven repository
behaves. So if the method was called:
searchTheStandardMavenRepositoriesForDependenciesAndCacheThermInTheGr
adleCache
then you would expect some behaviour that is not Maven standard.
However the method is called:
addMavenRepo
so there is some expectation that the behaviour will be that of
Maven
when it comes to looking up dependencies.
I guess people's expectations are very different. I'd expect
anything built
on top of Maven (e.g. a Maven plugin) to follow Maven's dependency
resolution mechanism, but I'd be very surprised if Gradle touched
Maven's
local repository (I wouldn't even recommend to share the local repo
between
two Maven installations).
addMavenRepo() means "add the (remote) Maven repository
http://maven1.repo.org";, and for my taste the method name
communicates this
fairly well.
This is exactly the way I see it.
- Hans
Here is the issue I run into with this in 0.5.2:
I have project foo over in this other directory structure. I
publish my
project using "gradle install". Everything goes well and the jar
ends up in
my maven cache.
I go back over to project bar and add a dependency for foo. The
build fails
because it cannot find foo unless I add my local maven cache in an
addMavenRepo(). Sort of counter-intuitive.
Maybe I'm too used to a maven-style workflow already. Is there some
other
way that I should be getting my gradle-produced jars from 'foo' into
the
gradle cache?
I see your point coming from a Maven perspective. But indeed the
Gradle workflow is different.
Gradle Multiproject builds do not use the Gradle cache (.gradle/cache)
for exchanging artifacts. The artifacts are stored in .gradle folders
within the multi-project builds. For integrating with other local
gradle projects which are not part of the same multi-project build,
you would publish to a local file system repository. This is the ivy
way of doing things (although, as you have done, you can declare your
cache as a repository). The use case for the Maven install task for my
perspective, is solely for integrating with local Maven builds. What
Gradle might should add to the java plugin, is a predefined local
repository, which resides in GRADLE_USER_HOME/local. The use case for
this repository would be integration with other Gradle builds, which
are not part of the same Gradle multi-project build.
- Hans
-Paul
--
View this message in context:
http://www.nabble.com/Maven-repository----I-should-know-the-answer-but...-tp19820914p22984109.html
Sent from the gradle-user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
