[ENH] Use gradle instead of ant

[phil-cd]

1. Motivation - We want to switch las2peer from ant to gradle. Even if this is not the main reason for using gradle, as a nice side effect, we then don't have to consider problems with updating ant anymore (see https://github.com/rwth-acis/las2peer/issues/75). We are currently using https://github.com/rwth-acis/las2peer/tree/gradle as a working branch.
2. Specification

• [x] It should be possible to build jar files for all the three components (core, restmapper and webconnector).
  • [X] Jar for core.
  • [X] Jar for restmapper.
  • [x] Jar for webconnector.
  • [x] Check if ant-created jars and gradle-created jars really contain the same content.
• [x] All tests (also previously used in ant) should be usable with gradle.
  • [x] Tests for core.
  • [x] Tests for restmapper.
  • [x] Tests for webconnector.
• [x] Building the node frontend needs to be possible with gradle.
• [X] Building the las2peer bundle (or fat jar) with gradle.
• [x] Javadoc (also for junitdoc in core)
• [x] Clean tasks
• [x] CI with travis.
• ~Build and publish to archiva with Jenkins.~ We decided to do this with GitHub actions from now on.

Feel free to add entries if something is still missing.

3. Finalised state - Everything that was possible with ant should be possible with gradle and ant should be completely removed from the project. In a later step, the template-project should also be updated.

[pedela]

If we now tackle the build process anyways, maybe we could we also consider

• [x] Investigate GitHub CI potential

• [ ] Investigate publishing Jar's with Travis

to this list? Would be nice to have this also done by Travis, this would in the future maybe allow us to switch to Travis and/or GitHub CI) completely/drop another dependency? I am aware this might slow down the release of this feature a bit, but it might be worthwhile in the longer run.

Opinions on this?

[phil-cd]

I totally agree on that. We should definitely have a look at it.

[ThoreKr]

In the activity tracker I switched to gradle and gave gh actions another try (first attempts in last years January were rather disappointing). It worked out surprisingly well. Especially how fast executions were (major boost compared to travis, still faster than gitlab ci).

https://github.com/rwth-acis/las2peer-ActivityTracker/blob/develop/.github/workflows/gradle.yml

[pedela]

I'd love to have you stay in contact with @phil-cd for this then:-)

[phil-cd]

@FBasels and I are already testing it out for las2peer in a fork (https://github.com/phil-cd/las2peer/actions). GitHub Actions also allows to get the artifacts and maybe it is also possible to send them to our archiva.

[pedela]

..awesome! Looking forward to your reports! Still, maybe you could include @ThoreKr to the party as well? The more, the merrier;-)