Switch to Maven on infrastructure

[andreaTP]

Ref: #37 (comment)

The maven test task is taking consistently less than gradle on clean projects.

Again, please verify that I'm not missing something ( 😉 @ErikSchierboom ), but now I'm pretty confident this is the way to go, I tested on a few Java exercises and this is taking about 1/2 the time than gradle.

There are additional considerations to be done regarding error messages since if we take this approach ppl will see a Maven output instead of the Gradle one.
Moving all the Java track exercises to Maven can be considered and will be mostly mechanical work (cc. @iHiD ).

[iHiD]

@andreaTP Thank you again :)

@exercism/java will need your thoughts on this please! It feels like a sane solution from an outsiders perspective, but I know nothing about any of this.

A naive question maybe, but do we need Gradle or Maven at all? As we know the dependencies that are used (basically none) can we do without those? Or are these things integral into the ability to run Java?

[andreaTP]

@iHiD compiling and running tests can be done using only java commands, here you have an example:
https://www.baeldung.com/junit-run-from-command-line

I warmly suggest not going in this direction, it will require a lot of maintenance since every little change to dependencies will change the commands and you would need to manually build the entire classpath (transitive dependencies included).
Additionally, although this is pretty much doable for plain Java, you are going to have much more trouble porting this approach to Groovy, Scala, Kotlin. The problem is solved using build tool plugins.

but I know nothing about any of this

I do have some availability to chat and share whatever is needed today and tomorrow.

[ErikSchierboom]

@andreaTP It looks to be working! I get between a 3-4 second speedup on my machine. From 13.6 seconds to 9-10 seconds. So as far as I'm concerned, this is definitely a good approach. I'll let someone from @exercism/java judge whether we need to convert everything to Maven. The downside of using Gradle for the exercises and Maven to run them are the different error messages?

[andreaTP]

The downside of using Gradle for the exercises and Maven to run them are the different error messages?

if the build tool setup is "fixed" and stable I would say that this is the only pitfall.

Regarding the wider subject of Maven vs. Gradle I do believe that the decision depends mostly on target audience.
Gradle is mostly used by Android developers and in recent codebases while Maven is the historical tool everyone used to build Java applications in the last 10 years.

That said if this PR fixes the original issue ( exercism/exercism#6097 ) I encourage you to go ahead and bring this to production, I do believe that is better to have slightly confusing error messages and stability other than repeated timeouts.

[mirkoperillo]

I think this is a big breaking change that should be eventually introduced very gradually ( yes I am a very conservative developer :) ).
I believe that the main factor is understanding what we do consider a good time saving for the introduction of this effort.

To open a discussion, what do you think about the following scenario:
2. Move test-runner to maven

1. Maintain (for the moment at least) the main track with Gradle.
2. Do a step of transformation here on test-runner from the exercise Gradle configuration to Maven one
3. Execute test runner against the exercise

If this could be possible it would bring some benefits:

• Improve the test-runner execution time.
• Do not introduce a big refactor of Java track without creating confusion to the students (in particular for those using the local version).
• A good test "on the way" to understand the impact of this refactor for many exercises.

I'm afraid to block the track because some bugs could rise that we haven't think about.

By the way in my opinion there are not problems for the representer, I don't currently know for the analyzer (I have to investigate).

[andreaTP]

a good time saving for the introduction of this effort

The Java track is timing out about 40% of the times, saving a few seconds should already be enough to prevent timeouts.

Move test-runner to maven

Those steps will be implemented simply by merging this PR and going to prod, the pom.xml is self-contained in this repo and no change is needed to the exercises themselves to go ahead.

Not sure about the "gradually" and the "possible bugs", tomorrow I will possibly still have some time to spend on this and eventually fix forward, starting next week I'll probably be less available.

[ErikSchierboom]

We don't have to convert all the exercises to Maven if I understand this correctly. The test runner seems to work fine with Gradle-based exercises, even when using Maven to run the tests. The key thing is that the test runner currently times out a lot, so as this PR shaves off 3-4 seconds, it might drastically cause the number of timeouts to drop. Is there any situation where using Maven in the test runner won't work with the Gradle exercises?

[andreaTP]

@ErikSchierboom

Is there any situation where using Maven in the test runner won't work with the Gradle exercises?

The answer is that Maven will behave the very same as Gradle on all of the tracks that are currently compiling with a build.gradle comparable to the one in the /exercise in this repo.

Doing a search in the https://github.com/exercism/java repo I can find 132 files build.gradle that conform to the canonical one + 3 that differ only because of whitespaces.
Note that the two lines:

compileJava.options.encoding = "UTF-8"
compileTestJava.options.encoding = "UTF-8"

are often omitted but this won't change anything unless ppl start to use strange file encodings.

There are although 2 build.gradle that are puzzling me:

• https://github.com/exercism/java/blob/acfdd2b654a1e2b8bb497c3af25a9e2eff1044e0/exercises/practice/hangman/build.gradle#L14
• https://github.com/exercism/java/blob/acfdd2b654a1e2b8bb497c3af25a9e2eff1044e0/exercises/practice/rest-api/build.gradle#L14

those 2 are declaring extra dependencies and I think that they are not going to work with the current runner, if they do run, the only explanation is that they match gradle internal dependencies (maybe @mirkoperillo have a more definitive answer for those cases 🙏 ).
A quick fix would be to explicitly add those dependencies to the pom.xml, let me know if I should do it or what I'm missing.

Let me know how you want to proceed! 🙂

[ErikSchierboom]

A quick fix would be to explicitly add those dependencies to the pom.xml, let me know if I should do it or what I'm missing.

That's exactly what should be done. Any dependencies used in exercises should be pre-loaded in the test runner.

[andreaTP]

@ErikSchierboom 👍 done here:
68d4781

[iHiD]

I think as Erik implies, the key thing is that currently the Java Test Runner (and other Java based languages) are all timing out on the website which is causing massive problems. So I feel like we need some fast solution for that. 100% that we don't want to break the track for students who already use it, but if this change only affects the test-runner, then I think this is a solid net-positive with little risk.

If I've misunderstood and this does affect the track and involve lots of changes, could someone make that clear pls?

@mirkoperillo Would love to get your 👍 on this today so we can try it if you're around and agree with what I've written above.

[mirkoperillo]

A quick fix would be to explicitly add those dependencies to the pom.xml, let me know if I should do it or what I'm missing.

@andreaTP Erik already answered about it.

The answer is that Maven will behave the very same as Gradle on all of the tracks that are currently compiling with a build.gradle comparable to the one in the /exercise in this repo.

It seems that the changes are only for this repo, so I am agree with you to try it

[ErikSchierboom]

Great! I've tested things a bit and it seems to work. Let's go!