What is the preferred gradle approach to locally install an artifact? (equivalent to maven's "install")

(hw.kirk) #1

In maven (1) there is the concept of “install” which places the artifact in MAVEN_HOME_LOCAL.

This location is always used to pickup dependencies by other maven projects. Does gradle have an equivalent concept of a local home???

The gradle cache appears to be something similar, but I am not sure.

I want to start getting the development team using gradle, but I don’t know what my approach should be for local installs.

A related issue is here: http://issues.gradle.org/browse/GRADLE-1615

Is there any additional recommendations you might have?

Thanks in advance.

(Patrick Wong) #2

The “publishToMavenLocal” task, provided by the “maven-publish” plugin - http://www.gradle.org/docs/current/userguide/publishing_maven.html

This goes to the exact same place that “mvn install” would put it.

(Peter Niederwieser) #3

First question is if you need such a place. For example, if you have a single multi-project build rather than many small builds, you won’t need such a place, and won’t have versioning issues between the components of your application. This is a convenient model. Another solution is to have your CI server constantly building snapshots which are then used in dependent builds. Again, this model is more reliable than exchanging artifacts via a local repository.

If you do need a local repository, only use Maven local if it’s necessary to exchange artifacts with Maven builds. Otherwise it’s better to declare a Maven or Ivy repository with a ‘file://’ URL.

PS: The Gradle cache is a cache in the real sense of the word. It’s only reason of existence is performance optimization. It isn’t possible to install anything there, which is important to achieve reproducible builds.

(hw.kirk) #4

Patrick: Thank you.

I am trying to avoid maven altogether, though I may need to rethink that and its good to know there is an option with publishToMavenLocal.

Peter: Yes, most of what you say matches my understanding.

We do produce our flagship financial product with about 20 maven1 builds, each producing a locally build artifact (and uniquely tagged),

The maven 1 multiproject is used and so the reactor determines ordering - and all artifacts will be pushed to a remote repo.

So…what I’m hearing is that I should not base my strategy on what maven 1 formerly provided but think about what I need and how I can use gradle to provide it.

It’s a good concept