Is it possible to have gradle search for dependencies locally with what is specify in the settings.gradle before going to the remote repositories event if we specify a remote dependency (not with project)?
The use case for this is suppose you need to work on several project that depend on each other, you want that if you compile a certain project, it should go and build it’s dependencies that is specify in settings.gradle and use the resulting artifact since it will be the real latest integration version (since you just build it).
If this is not possible how should you work with project that depend on each one? I have the feeling that having to build each one and publish an artifact individually could be error prone for the developer.
This isn’t something that Gradle provides out-of-the-box today, but it likely will in the future. To some extent, you can script it yourself (but it requires some effort). The alternative is to build all projects locally (i.e. use only project dependencies). Due to Gradle’s incremental build capabilities, the latter often works out fine.
I’m happy that you confirm that it will be provided in the future. As for the project only dependencies, the only catch to that is that I also want to have a CI like Jenkin that build each project individually (and deploy then inside a repository). If a developer needs to work on a project subset, he should just need to checkout and use a setting.gradle script to create a multi-project. All the other project that he didn’t checkout should be fetch from the external dependencies. Does that make any sense or should I revise my build logic.
It’s certainly one way to work. Another (which is easier to accomplish with Gradle today) is to have a single CI build and have every developer check out everything. Gradle’s incremental build often makes this more feasible than it sounds, and it avoids quite some complexity (inconsistent snapshots etc.).
I was hopping to avoid checking out the entire source tree for developing but it still goes into the right direction. Thanks a lot!
Out of curiosity, what would be the step to accomplish in order to script the initial question in Gradle? Just as a guideline for anyone who might wondering how to do it and have lots of time on there hands.
We are also already doing this, via a workspace plugin that is handling local vs. remote dependencies.
In our case we add a dependency between the task that unpacks a dependency on the task that uploads an artifact to the repo. This then assumes that we let the project be its own beast and that we use the same mechanism as if you would have been working on the projects independently.
In other words, we always go via the repo to fetch a dependency.
Peter, your way is perhaps a more elegant way of doing it, but it assumes that there is a settings.gradle that contains all components that could be locally found. In our case we generate that when a component is cloned into the workspace (via our plugin). Good to know there is another way to do it though.
We are starting to apply the gradle at work, we also have the need to do this, it is actually a must-have, it would be really nice to have this ability out of the box for Gradle.
We already do this to and have moved our implementation into gradle (we’ve used several build systems). basically, we always have a build number in our versions. Our CI builds use the standard build number from the CI job (Jenkins in our case). Any local builds always use a timestamp. Because the timestamp as a build number is always larger than the CI build number, local builds always take precendence.
There’s a couple clunky things with this implementation. The main one is that for ease of use, we always pad the CI buildnumbers with zeros so they are 14 digits like a timestamp. This makes handling the artifact nomenclature standard so that regexes in a few spots can be simple.
I like several of the ideas put forth above and look forward to built in support of local vs. remote artifacts in Gradle in the future.