Visitar URL original
Use SDKMAN to install Ant and Java · Issue #368 · jython/jython · GitHub
Skip to content

Use SDKMAN to install Ant and Java #368

Description

@wfouche

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

# Enable auto-env through the sdkman_auto_env config
# Add key=value pairs of SDKs to use below

# Ant
ant=1.10.14

# Java
java=8.0.442-tem

Ant and Java is installed by simply running the following command:

$ sdk env

or if the requested versions of Ant and Java are not yet localled cached

$ sdk env install

Activity

  1. jeff5 commented on May 4, 2025

    @jeff5
    Member

    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.

  2. koppor commented on May 16, 2025

    @koppor

    .sdkmanrc files are also compatible with mise. One could even set both the required java and python version.

    Note that java@21 is perfectly valid. Thus, no micro-versioning, but "pinning" to some main java releases.

  3. wfouche commented on Jun 3, 2025

    @wfouche
    MemberAuthor

    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.

    Image

    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.

    Image

  4. wfouche commented on Jun 3, 2025

    @wfouche
    MemberAuthor

    .sdkmanrc files are also compatible with mise.
    One could even set both the required java and python version.

    @koppor , I'm not familiar with mise but will check it out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions