The extendedJavaHome environment variable contains `.` symbols in the version. This causes the environment variable to be ignored by the action runner. It's best to replace those and other non standard symbols with and underscore.
For reference:
> Environment variable names used by the utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001 consist solely of uppercase letters, digits, and the '_' (underscore) from the characters defined in Portable Character Set .
This will support specifying EA versions in the following format examples. E.g.:
14-ea
14.0.0-ea
14.0.0-ea.28
Notes:
- For the last form above, which is needed for requesting a specific ea build, we must only add '.x' if there are less than 3 dots in the version, hence the change from != 3 to < 3
- The prior parsing logic for e.g. 14.0.0-ea "spelling" will ignore precedence between build numbers in the form of e.g. 14.0.0-ea+b27 vs. 14.0.0-ea+b27 (so it will end up with the earliest rather than the latest ea build in the cdn), and does not allow specifying an ea build number (it will match 14.0.0-ea+b29 to a cdn 14.0.0-ea+b2). The new logic [copupled with the CDN populating EA builds in the form 14.0.0-ea.28) will resolve that.
* Add java-package parameter to action, support jre, jdk, and jdk+fx (#1)
* Update tests to use 'jdk', 'jre', and 'jdk+fx' javaPackage parameters
* Match extension only at end of line
* Update README.md
* Update workflow to use 'node-version' instead of deprecated 'version'
* Initial attempt
* Clean up
* Extract right directory
* Log whats happening
* Read correct directory
* Full path
* Allow java to be found in cache
* Add tests
Arthur Baars