feat: Add input option add-toolchain-only

[mhoffrog]

Description:
In case of installing multiple Java versions, this option will add a subsequent installed JDK to the Maven toolchains.xml only without updating Maven settings.xml nor updating environment vars JAVA_HOME and PATH.

Changes

• Add input option add-toolchain-only - default: false
• Propagate default values for set-default and overwrite-settings from add-toolchain-only
• setup-java.ts:
  • couple of code improvements for less error prone interface instancing
  • single place for reading input of overwrite-settings
• toolchain.ts, auth.ts:
  • replace reading of input overwrite-setting by passing overwriteSettings and addToolchain as method parameters
• tests/toolchains.test.ts: followup previous changes
• documentation updated in README.md and docs/advanced-usage.md.

Related issue:
Closes #1047 - Followup Issue of #553

@brunoborges - many thanks for having created #1047.

Check list:

• Ran npm run check locally (format, lint, build, test) and all checks pass.
• Mark if documentation changes are required.
• Mark if tests were added or updated to cover the changes.

[mhoffrog]

Put to draft now to await merge of #1111.

[brunoborges]

@mhoffrog I am not sure about this new feature. I think it adds complexity. What is the downside of having more JDKs installed with their specific environment variables configured? What is the real point in adding JDKs to the tool chain but not to settings.xml ?

[mhoffrog]

@mhoffrog I am not sure about this new feature. I think it adds complexity. What is the downside of having more JDKs installed with their specific environment variables configured? What is the real point in adding JDKs to the tool chain but not to settings.xml ?

Typically you have one JDK being your default JDK and you have to setup settings.xml only once. settings.xml does not know anything about JDKs installed. Settings.xml is about providing credentials and repository URLs. Multiple JDKs in toolchains.xml is typical scnario, since your POMs will define the toolchain for compiling and any plugin looking up toolchain config. Your Maven build job may have to run by another JDK, since Maven plugins have their own requirement to run on. Maven toolchain is to separate compile and unit testing JDks from Maven build job executing JDK.

Similar for Gradle - you will run your Gradle build job with JDK A and you may have unit and integration testing demands with a matrix of JDKs to perform.

What is the downside of having more JDKs installed with their specific environment variables configured?

This is exactly what is to be avoided. There must be only a single environment var JAVA_HOME and PATH setting over all. Toolchains is to capture any other JDK required by your build job. This is less complexity at the end.

[brunoborges]

Ok, but what is the problem with the current capabilities? You do get different JDKs configured in the toolchains for the example you gave.

[mhoffrog]

Ok, but what is the problem with the current capabilities? You do get different JDKs configured in the toolchains for the example you gave.

The current behavior is that with each additional JDK installed settings.xml will be overwritten. You can disable this by disabling overwriting, but then also toolchains will not get added the additional JDK. In addition you may disable set-default - but you have to do this for each particular additional JDK setup. This is more config hell than otherwise.

[mhoffrog]

@brunoborges This PR may become obsolete, in case #1111 will have been merged. With #1111 toolchains will be updated/enhanced in any case. By that given, add-toolchain-only will be adequate to:

• set-default: false and
• overwrite-settings: false

So there is no need to add another input for that. The only use case not covered anymore will be to disable toolchains update.

Please let me know, if this is as intended, then I will close this PR accordingly.

[mhoffrog]

Closing this PR since use case can be resolved as described above. If there is need to disable toolchains update for some reason, a new feature request should be created.