Currently the resolved version is cached. For example something like 8.0.141.
On other hand when a version is looked up in the cache the string provided
by the user is used. This may lead to unexpected behavior. 1.8 will not match
8.0.141. Normalizing the version string before looking up in the tool cache
will solve the problem. The normalized version (8.x) will match the
entry in the cache as expected.
Normalizing the string in the beginning of the flow won't hurt
as it is a valid version specification. What is more it the user can supply
the normalized version directly so the code should be able to work with it.
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
