Jump to content

Gradle Dependency Solutions for Public Projects without Maven Artifacts


Recommended Posts

Posted

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.

 

build.gradle

buildscript {
    repositories {
        jcenter()
        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:

 

settings.gradle

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

 

build.gradle

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?

 

[move]Perry[/move]

 

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.

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

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • https://mclo.gs/46Xf7Sq thanks
    • That seems to have fixed it, thank you!
    • I am having some issues starting an RLCraft server on a minimal install of Debian 12. I have Java installed and I'm able to start the vanilla Minecraft server jar no problem and people can join and play without any issues, as soon as I try to create a new directory with the Forge jar the initial install with the INSTALLER jar works when I use the java command with the --installServer flag, but as soon as I try to start the server using the forge jar that is NOT labelled with installer I get the following error: A problem occurred running the Server launcher.java.lang.reflect.InvocationTargetException         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)         at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)         at java.base/java.lang.reflect.Method.invoke(Method.java:569)         at net.minecraftforge.fml.relauncher.ServerLaunchWrapper.run(ServerLaunchWrapper.java:70)         at net.minecraftforge.fml.relauncher.ServerLaunchWrapper.main(ServerLaunchWrapper.java:34) Caused by: java.lang.ClassCastException: class jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to class java.net.URLClassLoader (jdk.internal.loader.ClassLoaders$AppClassLoader and java.net.URLClassLoader are in module java.base of loader 'bootstrap')         at net.minecraft.launchwrapper.Launch.<init>(Launch.java:34)         at net.minecraft.launchwrapper.Launch.main(Launch.java:28)         ... 6 more   I have tried using newer versions of Java directly from Oracle as well. Has anybody been successful in starting and running a RLCraft server from the terminal on a Linux machine? I cannot figure out why it doesn't want to work but the vanilla jar works without issue. Thank you in advance!
    • This is my latest attempt :  public class ManaScreen extends Screen { Mana mana = new Mana(); boolean removeManaBar = false; ResourceLocation manaBar = ResourceLocation.fromNamespaceAndPath(RSGArmoury.MOD_ID, "/textures/block/spawnable_arena_wall.png"); public ManaScreen() { super(Component.literal("Mana")); } @Override protected void init() { super.init(); Minecraft.getInstance().setScreen(this); } @Override public boolean isPauseScreen() { return false; } @Override public void render(GuiGraphics pGuiGraphics, int pMouseX, int pMouseY, float pPartialTick) { pGuiGraphics.blit(manaBar, 10, -10, 0, 0, mana.getMana(), 10, mana.getMana(), 10); if (removeManaBar) { this.onClose(); return; } super.render(pGuiGraphics, pMouseX, pMouseY, pPartialTick); } public void addManaBar() { removeManaBar = false; Minecraft.getInstance().setScreen(new ManaScreen()); } public boolean removeManaBar() { return removeManaBar = true; } }
  • Topics

×
×
  • Create New...

Important Information

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