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?

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

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.

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

includeBuild

is creating

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.

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

./gradlew build

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.

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

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()

.

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. 🙂

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?

No, Gradle does not such stupid mixture.