Jump to content

Gradle Dependency Solutions for Public Projects without Maven Artifacts


Recommended Posts

I'm interested to know what solutions people have come up with for Gradle dependencies on public projects that do not publish maven artifacts.


A simple solution is to download the deobfuscated JAR or build it locally then drop it in the libs folder. Not only does this involve a fiddly manual task but it can cause problems with automated builds. For my Jenkins server to successfully build I would need to include the JAR in my git repo which I don't want to do for copyright reasons nor do I want to constantly be pushing a binary blob up to my server.


My current solution is to add a git clone task the buildscript that fetches a github repo. Though I haven't yet figured out how to set up the dependencies so that clone is executed automatically.



buildscript {
    repositories {
        maven {
            name = "forge"
            url = "http://files.minecraftforge.net/maven"
    dependencies {
        classpath 'net.minecraftforge.gradle:ForgeGradle:2.2-SNAPSHOT'
        classpath 'org.ajoberstar:gradle-git:0.6.3'


clone.dependsOn {
    tasks.findAll { task -> !task.name.equals("clone") && task.name.startsWith('clone') }

task cloneMod(type: GitClone) {
    def destination = file("../mod")
    uri = "https://github.com/user/mod.git"
    branch = "1.9.4"
    destinationPath = destination
    bare = false
    enabled = !destination.exists()


Then in settings.gradle I include the project and add it as a dependency in build.gradle:



include ':mod'
project(':mod').projectDir = new File(settingsDir, '../mod')



dependencies {
    compile project(':mod')


With this set up I can get a successful build with gradlew clone && gradlew build.


This solution should also involve a pull to get the latest updates for the given branch but I haven't gotten that far yet as I'm not sure if I'm going to keep handle dependencies like this.


This approach has several drawbacks however. For one builds are much slower as Gradle has to spool up and run through all the tasks on the dependent mod, even if the tasks are up to date it still takes a while before we get to building our own mod.


Additionally it seems that tasks like gradlew runClient will run for both projects. This means that after closing the one instance on MineCraft another one will start up. It's quite annoying but can be avoided if you halt the gradle task before closing the first instance. I'm sure there's a way to avoid this in the build script but I currently haven't figured that out yet.


Another option could be to use my Jenkins server to compile dependent mods. I could then either figure out a Jenkins script to publish artifacts to my own maven repo which my mods build.gradle can use as a dependency. Though this would probably also cause some copyright issues as I would be publicly distributing other peoples mods.


The other option for this approach could be to push the scripting to mod's build.gradle where a script could check if we have the latest Jenkins build. If we don't have the latest build it would remove the old one and pull down the latest deobfuscated JAR to the libs folder. I believe it this would be fine so long as downloading artifacts requires authentication on the Jenkins server.


A third option that I am warming to would be a variant on my current solution but without depending on a sub project. Instead the script would check if we have the mod JAR in libs, if not it would clone, build, and copy the deobfuscated JAR into the libs folder. I'm sure there would be opportunity to code in version numbers / commit IDs to have more control over which version of the mod we need to depend on.


Fourth option.. I could ask the mod author to publish artifacts.


Thoughts? Anyone else have any solutions?




Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...

Important Information

By using this site, you agree to our Terms of Use.