Cannot deliver jar file via the JSON api

[kytrinyx]

The API currently blows up when trying to serve java problems, due to the non-utf-8 characters in the gradle archive.

It is perhaps a bit excessive to serve a jar file with each problem. Should we provide a link to the jar and have people download it and put it in their PATH?

Should we simplify the testing? (we really don't need anything fancy, the problems are all very tiny).

[chelseakomlo]

I'll send this along by later today to someone who will have great opinions on this!

[sit]

The reason I initially put the jar file in was to make it dirt simple to build; no installing any other tools besides Java. Can the JSON API (and client...) be taught to b64 encode the jar or something like that?

[kytrinyx]

make it dirt simple to build

I'm definitely all for dirt simple. Installation and setup is a real thorn.

I'm sure the JSON API could be taught to encode the jar file, but I think I would rather have people download one jar file once, than to deliver it each time.

[kytrinyx]

@BillSchofield did some work to see if it's possible to have a single gradle jar file. It looks very promising, I just need to run through it and decide what the setup steps would be

https://github.com/BillSchofield/xjava.git

[kytrinyx]

I've merged @BillSchofield's branch into master, and added an incomplete (and wrong) documentation page for how to get started: http://help.exercism.io/getting-started-with-java.html

I can't figure out what the steps are to run the tests as an exercism user.

Given that I have the exercism CLI installed (https://github.com/exercism/cli/releases/latest), and that it is configured, I want to be able to say:

exercism fetch java bob

And then follow some sort of instructions to be able to run the tests.

What files would I need to download from this repository in order to do that?

/cc @MoreNaruto @brmenchl @edrobal @chelseakomlo @charltonaustin @gitjulia @contraption

[jtigger]

Spoke with @kytrinyx about this, this morning. Since this discussion, we've (rather by default) apparently settled on using a dependency management tool (i.e. Gradle). Effectively, issue closed.