Create toolchains.xml dynamically based on envs

[hfhbd]

Fixes #89

The GitHub runners contain the JAVA_HOME_ envs by default (even without setup-java), so we can use the envs to create the toolchain.xml dynamically.

[bigdaz]

Thanks for the PR! Quick question prior to a full review: have you checked that it is OK to omit the '' element from the entries in toolchains.xml?

[bigdaz]

Also, can you please push this without the changes to the dist directory? That will make it easier to merge.

(Long term we need to find a better way to manage the dist directory, perhaps via a workflow that runs automatically on pushes to main.)

[hfhbd]

the '' element

I guess you mean the vendor? I didn't run a test but I looked up the jdk maven toolchain specification which requires only the jdk home. But after thinking about it again, I guess! it would be needed/helpful for Gradle Toolchains which also uses the vendor.
So I will add the default vendor (Eclipse) back.

[bigdaz]

the '' element

I guess you mean the vendor? I didn't run a test but I looked up the jdk maven toolchain specification which requires only the jdk home. But after thinking about it again, I guess! it would be needed/helpful for Gradle Toolchains which also uses the vendor. So I will add the default vendor (Eclipse) back.

Hah, yes I typed <vendor/> but I guess that got stripped!

I suspect that Gradle is only using the env vars to locate the JDK, and then executing java --version to determine the rest. But I'm not sure, but shouldn't be too hard to confirm.

Ideally, we'd omit anything redundant (like "Eclipse"), especially if it's hard-coded and possibly incorrect.

[hfhbd]

Yes, you are right, Gradle just extracts the env entries and calls java --version by itself, so I will drop it.

[hfhbd]

Closed by #150

[bigdaz]

Thanks for the contribution @hfhbd!
I've been making a bunch of changes to the CI workflow, and in order to test these I created and merged a new PR (#150) with these changes.

That said, there's one small improvement that would be nice.
Currently, the logic for merging the generated toolchains.xml file with an existing one is in the GradleUserHomeCache.registerToolchains() method.
Instead, it would be good to have a separate method that did this work, with a little unit test coverage.

If you're willing to help out, this would be a nice experiment to see how the new CI process works with a forked repository. Ideally, you'll be able to enable the actions for your fork and everything should pass in your repo. Then the workflows should be applied in this repo once your PR is submitted and the workflows approved. I'm sure there will be some things not working, but hopefully the process will be smoother.