I’m looking for help importing a gradle dependency...

# getting-started

[Nathan Kleinschmidt]

I’m looking for help importing a gradle dependency from a github repo. It looks like I would clone the package code into my project and then reference it in my build.gradle.kts using implementation(files(./dependency)). My question is which path exactly do I need to reference?

[Joffrey]

Is the GitHub repo published as a library somewhere? For instance on Maven? If it is, it would be a better alternative to depend on that library directly via it's maven coordinates.

Otherwise, if that project itself is built using Gradle, you could also use the includeBuild feature from settings.gradle.kts

[Joffrey]

How do you expect to get updates from that GitHub repo?

[Nathan Kleinschmidt]

Thanks - I’ll try includeBuild. I’m not particularly worried about updates since I can always pull them from the repo. This would be mostly for development purposes, as a way to run code that was maybe not yet published to Maven. Someone else recommended looking into gradle composite builds.

[Vampire]

Yes, composite builds is what you want. That is what includeBuild is creating

[Vampire]

If you don't intend to modify the project, but only want to use bleeding edge code, there are two other options.
If the project is publishing snapshot versions, you can use those.
If not, you could use https://melix.github.io/includegit-gradle-plugin/latest/index.html which also takes care of cloning the repo and updating for your, additionally to configuring it as included build.

[Emerson Farrugia]

If it's a third-party project you want to keep isolated from your own, you can also clone the third-party repo, add a publishing configuration to build the binary dependency and store it in mavenLocal(), and configure your own project to resolve dependencies from mavenLocal to get the binary from there.

[Nathan Kleinschmidt]

There are no snapshot versions as far as I can tell, only build instructions via ./gradlew build

[Vampire]

If it's a third-party project you want to keep isolated from your own, you can also clone the third-party repo, add a publishing configuration to build the binary dependency and store it in mavenLocal(), and configure your own project to resolve dependencies from mavenLocal to get the binary from there.

But why use the Maven style when you can do it much more convenient using composite build?
Besides that mavenLocal should be avoided wherever possible, or at most be used with a content filter, as it is broken by design.

[Joffrey]

Hey Björn, do you mind expanding on the brokenness of maven local? We are using it locally to emulate a maven server for several artifacts downloaded dynamically at runtime, where production code would actually call a remote repo, and I'd be interested in knowing potential problems if you have specifics in mind

[Vampire]

The default maven local for Maven is not a simple repository, it is a mixture of repository and download cache.
If you for example just resolve the POM using Maven, just the POM is in maven local. Or if you resolve the POM and the main jar, only these are in maven local.
If now Gradle comes and sees the pom, it assumes the entry is complete which often is not the case and can lead to strange behavior and hard to diagnoes build bugs.
Whenever you use mavenLocal(), it should be the last in the list and you should optimally always use a repository content filter to define which exact dependencies to take from it where you know they are in proper shape.

Alternatively, especially in your use-case, use any other dedicated local directory as repository, it does not have to be mavenLocal().

[Emerson Farrugia]

But why use the Maven style when you can do it much more convenient using composite build?

It's just an alternative, and it'd work if the dependency is built from a Maven project rather than a Gradle one (it wasn't clear from the question, and I'm still not sure after re-reading it.) Composite builds also effectively ignore version numbers, which can be problematic if you need to switch between local and published versions for testing purposes.

But FWIW, I agree that composite builds are the saner solution. 🙂

[Joffrey]

Thanks @Vampire, very helpful! I think in my case it's fine, the use of maven local is really only through publishToMavenLocal of one module, and then using that repo at runtime to download the corresponding artifact, so it will be completely there. I wasn't aware that generally we couldn't expect the complete artifact files to be there. That's only when using Maven, right? Or does Gradle do the same thing?

[Vampire]

No, Gradle does not such stupid mixture.