How to build and use a dependency locally which is normally remotely provided via CI?

Old Forum
1

In our development setup we have several projects which depend on one common-project. The common-project build is provided by a central build via nexus. This work as expected.

Sometimes I make local changes to the common-project and want to test its effects on my dependent project by bypassing the CI by build both projects locally. So I do it the maven way and use the maven local repository in order to install the modified common-project artifacts there.

When now configuring the maven local repository as input repository for the dependent project I face tow issues: -in case the maven local repository is the first one the build instantly quit with an error because the first dependency of the common-project cannot be resolved (its a plugin) -in case the maven local repository is the last one it doesn’t take the newer version of the maven local repository into account

repositories {
  //mavenLocal()
//doesn't work at all
  maven{ url 'http://10.150.225.29:8080/nexus/content/groups/snapshot'}
  //mavenLocal()
//doesn't update the dependency to the newer one located in maven local repository
}

So what is the proposed way to build and use a dependency locally which is normally remotely provided via CI? David

2

‘mavenLocal()’ is currently the simplest way, and yes you’ll have to add it before your regular repo. Why does common-project have a build dependency on a (Maven?) plugin, and why can’t that plugin be resolved?

3

sorry this was my fault.

Many thanks for reply

4

I’m looking for something similar to this as well, but I can’t find any documentation on mavenLocal(). Can you provide a simple example of how this would work? Would you still need to install the common project into mavenLocal before compiling the other projects?

5

What about this as an alternative to mavenLocal():

repositories {

flatDir {

dirs(allprojects.findAll{it.hasProperty(‘libsDir’)}.

collect{it.libsDir})

}

}

I haven’t tried to run this, so the syntax might not be correct. This is admittedly a shotgun approach. In a real project with any complexity you’d probably want to limit the projects that are included. But it has the advantage in that you don’t have to run any special tasks to deploy the common jar to a local repository.

6

Yes you need to place your base artifacts somewhere where Gradle can resolve them from. This is the same as with Maven. A standard repository like Maven or Ivy is the all-round carefree package because it defines the repository layout so Gradle just knows how to deal with it.