https://kotlinlang.org logo
#getting-started
Title
# getting-started
n

Nathan Kleinschmidt

03/27/2022, 3:04 PM
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?
j

Joffrey

03/27/2022, 3:07 PM
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
How do you expect to get updates from that GitHub repo?
n

Nathan Kleinschmidt

03/27/2022, 4:29 PM
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.
v

Vampire

03/27/2022, 4:40 PM
Yes, composite builds is what you want. That is what
includeBuild
is creating
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.
e

Emerson Farrugia

03/27/2022, 4:44 PM
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.
n

Nathan Kleinschmidt

03/27/2022, 4:46 PM
There are no snapshot versions as far as I can tell, only build instructions via
./gradlew build
v

Vampire

03/27/2022, 5:07 PM
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.
j

Joffrey

03/27/2022, 5:10 PM
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
v

Vampire

03/27/2022, 5:16 PM
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()
.
🙏 1
e

Emerson Farrugia

03/27/2022, 7:54 PM
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. 🙂
j

Joffrey

03/28/2022, 12:12 AM
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?
v

Vampire

03/28/2022, 12:17 AM
No, Gradle does not such stupid mixture.
👌 1
2 Views