Repository navigation
Use SDKMAN to install Ant and Java #368
Description
Activity
SDKMAN seems like a useful thing, so I guess one would also want to have its configuration file in the development environment. From the documentation, there's some friction involved when using it on Windows, so I may only adopt it myself on the holiday laptop, which is Linux.
I don't tear my development environment down between tasks, as one might a Python virtual environment and re-build it from the requirements file. Those who develop using a containerised IDE might appreciate the configuration arriving with the project files. Is the idea to support that kind of working? Isn't there usually a user-specific profile too?
As things stand, though, we don't check-in configuration files for IDEs, but "support" those IDEs through
.gitignore.I notice these pin the build tool and JDK to particular micro-versions. Won't we find we're either pinned to an old version, or constantly updating this file? I think the argument is different for dependencies (JARs) that we bundle in the fat JARs or communicate in the POM, because we test with those. Even there, it is a real nuisance if it really matters exactly which versions are used.
.sdkmanrcfiles are also compatible withmise. One could even set both the requiredjavaandpythonversion.Note that
java@21is perfectly valid. Thus, no micro-versioning, but "pinning" to some main java releases.there's some friction involved when using it on Windows
@jeff5, not too much friction. I use it rather seamlessly via Git-Bash after also installing zip.exe which is needed by the SDKMAN install script run from Git-Bash. Once SDKMAN is installed, it is very simple to use it to activate a known tool set.
I just ran the following commands on my Windows PC just now.
Is the idea to support that kind of working?
No. IDE specific information is not stored.
Isn't there usually a user-specific profile too?
No. User specific information is not saved.
SDKMAN simply ensures that the correct version of the required build tools are activated and made available on the command-line.
I notice these pin the build tool and JDK to particular micro-versions.
Won't we find we're either pinned to an old version, or constantly updating this file?The upside of pinning the versions is that all developers then have bug-compatible versions of the build tools and should consistently see / encounter the same issues or be able to reproduce issues reported by other developers.
The tool versions should not have to change often, maybe only once or twice a year.
The Spring Framework use SDKMAN to specify the version of Java to use to build Spring, see .sdkmanrc file:
The Git-Bash shell can be registered with the Windows Terminal program, making it easy to choose which shell program to use for a specific command-line session.


Adding a .sdkmanrc file to the Jython repo, will allow the correct latest stable versions of Ant and Java to be installed with less effort.
.sdkmanrc
Ant and Java is installed by simply running the following command:
or if the requested versions of Ant and Java are not yet localled cached