Replace mvn and bash scripts with gradle

[peterdietz]

I've added gradle as a build/compile/test/run/dependency-management tool. It replaces mvn. (I haven't yet removed maven pom).

Even without installing any tools, you should be able to get up and running quickly:

linux/osx:
./gradlew run --args="-c src/sample_data/AAA_batch-metadata.csv"

windows:
gradlew.bat run --args="-c src/sample_data/AAA_batch-metadata.csv"

if you already have gradle installed, use your system install of gradle:
gradle run --args="-c src/sample_data/AAA_batch-metadata.csv"

The tests pass:

./gradlew test

> Task :compileTestJava
warning: [options] bootstrap class path not set in conjunction with -source 1.6
1 warning

BUILD SUCCESSFUL in 1s
3 actionable tasks: 2 executed, 1 up-to-date

[tdonohue]

@peterdietz : while I'm not against this PR, it's a bit of a change for anyone familiar with installing DSpace (which obviously uses Maven over Gradle). If the main goal here is just to make this easier to build/install, you could consider instead using Maven Wrapper (mvnw) which acts similar to gradlew: https://github.com/takari/maven-wrapper

(I've thought myself about whether we should be using mvnw for DSpace, but haven't gotten around to it quite yet. Gradle is also honestly interesting to consider longer term, but much harder to implement for all of DSpace. We just have a very complex build process that would take significant effort to swap over)

[peterdietz]

Hi @tdonohue I've only just realized the wisdom of Mark Wood's (4 year old) PR to create an executable JAR. #8

I was thinking the answer was to make it easier to compile the project (gradle-wrapper or perhaps maven-wrapper), when really, it could just be, ship a pre-compiled jar (this is java, we're portable). And have easy instructions for the librarian using a windows computer to just run it without having to install dependencies. I recently merged that, and added documentation for how to do that. https://github.com/DSpace-Labs/SAFBuilder/releases/tag/v1.6

I get occasional emails from people running this project, and stumbling on JDK/MVN, and I've shared the jar instructions, and its already worked for a user. So, my main compelling reason (make it easy for end user to get up and running quickly) has been solved. And mvn --> gradle, is just a technology question, that I suppose one could weigh pro's/con's. My goal is mostly to make it really easy to use (for users and developers) to rock and roll. Developers will probably figure out mvn/gradle more or less the same.

Yeah, I don't need to migrate to gradle, especially if it makes sense for the whole of DSpace to stick with a common build tool, that way, if someone needed to support a maven build issue, the knowledge is already there. At the same time, this is an independent project, without complex build steps, so its probably no big deal. I'd also want to avoid having maven and gradle (dual compatibility, it does work...) since then you would need to update dependency versions in two places, instructions in two places, a mess. Just figure it out, and rip the bandaid off.

Anyways, I'm fine on pausing on the gradle, especially since I'm not actively using this project.