Port luaj to Gradle and improve build script

[dmarcuse]

In this PR I've ported LuaJ from ant to Gradle, and then added it as a subproject dependency for the main project (CC itself). This means that 1) dedicated deploy and build_luaj script are no longer needed, you can simply run ./gradlew build to get a functional jar (which also contains luaj automatically). This also makes it much easier for people trying to use CC as a dependency in their own projects, because LuaJ is now properly registered as a dependency and included in the output jar.

I'm happy to make changes if necessary, just leave a comment if there's anything I should do.

[SquidDev]

I wonder if it would be worth adding CurseGradle support? This means you can upload to CurseForge with a single Gradle command (./gradlew build curseforge). Something like:

plugins {
    id 'com.matthewprenger.cursegradle' version '1.0.8'
}
curseforge {
	apiKey = project.hasProperty('curseForgeApiKey') ? project.curseForgeApiKey : ''

	project {
		id = '67504'
		releaseType = 'release'
		changelog = ''
	}
}

You can then define a Curse API key in ~/.gradle/gradle.properties and it all "just works". I think it would be worth checking with Dan before adding this though.

[dmarcuse]

I like the idea of CurseGradle, but as it's something that would only be used by Dan it should be up to him as you said.

[JLLeitschuh]

The curse key could be encrypted and embedded in travis environment for auto-releases there. Again, something dan would need to do.

[dan200]

This is a gargantuan commit just to avoid having to type "./build_luaj.sh" on the once in a blue moon you make a change to the luaj sources, no? Is the objection because that script doesn't work on windows? Because I'm sure we could make a .bat file easilly.

[dmarcuse]

The point of this PR is two things mostly: 1 - no more need for separate scripts to build things, you can do it all from gradle easily which eliminates compatibility issues (e.g. needing to install unzip package for the deploy script to work) 2 - adding luaj to the dependencies of the project properly (rather than /lib/) and packaging it into the gradle output jar allows it to work properly when CC itself is used as a dependency. For example, while attempting to port CCEmuX to use the new open source repository, it was impossible to get it working because the gradle artifacts neither contained luaj nor required luaj as a dependency, so the classes were not present.

Additionally, there are various buildscript improvements such as setting the target and source compatibility to ensure that everything works with old Java versions, and adding better support for Eclipse.

I got a bit delete-happy with the scripts, I'll add them back - setup.sh, setup.bat only, or any of the others as well?

[dan200]

I would keep them all except build_luaj.sh, even if all they do is call through to the gradlew

[dmarcuse]

Would you be opposed to me rewriting the scripts as Gradle tasks? This eliminates compatibility issues and makes them work properly across operating systems - e.g. ./gradlew deploy, ./gradlew ideSetup, etc.

If you like, I can still add scripts that simply call these tasks, this would just make it easier to maintain compatibility.

[dmarcuse]

@dan200 I've added back the functionality from the scripts (as Gradle tasks) and added wrappers for the tasks, could you review this again and let me know if anything else should be changed?

[SquidDev]

From what I can tell this doesn't package the API source or documentation in the JAR. I think you can do it like this:

javadoc {
    include "dan200/computercraft/api/**/*.java"
}

jar {
    dependsOn javadoc
    into("docs", {  from(javadoc.destinationDir) })
    into("api", { from (sourceSets.main) {
        include "dan200/computercraft/api/**/*.java"
    }})
}

[SquidDev]

I'd really like to see this merged, or at least a trimmed down version of it. There have been several people on IRC, various discords and the forums wondering why ComputerCraft "doesn't work", not realising they need to use the ./deploy.sh script - and even then having issues. Doing the bundling inside the Gradle task would be much less confusing for everyone.

[KnightMiner]

I also would like to see this get merged. I currently have to manually copy the Lua dependency into my mods folder (Forge classpath injection feature) since the scripts do not seem to function fully on Windows.

[Lupus590]

I'm not an expert on Java or Gradle yet, but there seems to be a lot of noise/unrelated changes in that last commit.

[Lignum]

@lupus590 It's because it's a merge commit, all those changes are just catching up. They shouldn't appear in the "Files changed" tab

[SquidDev]

@lupus590 He merged several hundred commits, so there is going to be a little bit of noise :).

@apemanzilla I wonder if it would be better to rebase the PR and squash everything so it's a little clearer what's changed. It might be worth reverting the LuaJ layout change, and just getting gradle to point to different directories - that way the change list is a little less murky.

[KnightMiner]

Might be good to rebase this just to prevent odd errors rather than the merge commit, I've seen issues from merge commits with conflicts before.

[dmarcuse]

Yeah, I should have rebased instead of merging, didn't realize it was that many commits behind...

Either way, as stated before, if you use the Files Changed button at the top you'll see the actual changes.