-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A way to specify asdf shell java 11
#92
Comments
@dkowis Which of the supported OpenJDK distributions (AdoptOpenJDK, Amazon Corretto, Zulu Community) and in which variant (OpenJ9, large heap) would you expect to be used when using |
asedf shell java 11
asdf shell java 11
Without being opinionated, I wouldn't expect it to install one, as that's terribly ambiguous. But to take an opinionated software stance, I'd pick an AdoptOpenJDK 11, hotspot variant, if one wasn't specified. I think it's okay to be moderately opinionated for simplicity's sake during an install, as you can choose explicitly the other ones, if you want them :) I was thinking about the version file being able to pick some java 11 after it's installed. I'm open to other ideas, of course! I would just like the convenience of being able to specify a "java 11" in my java tool file, without having to be explicit, unless I wanted that specificity. Most often, I'll update patch levels of java and I don't think I should have to update all my I'm also open to more interesting version parsing logic (which might be hard!) things like It would be a significantly more complex (and awesome!) version parsing logic though. |
You can symlink one specific version to the name 11, just run:
and then:
You can replace adopt-openjdk-11.0.7+10 with the latest candidate that you consider the canon "11" |
I think adding an alias can be done using: https://asdf-vm.com/#/plugins-create?id=extension-commands-for-asdf-cli I'm currently thinking about adding
For adding aliases https://github.com/andrewthauer/asdf-alias sounds like the better option. |
@delgurth there's a plugin for that same functionality, take a look at https://github.com/andrewthauer/asdf-alias |
@augustobmoura thanks, guess we need to add a bin/help.links to link to this plugin as a useful companion plugin. |
@augustobmoura have you used this plugin successfully? I first tried the regular version, first facepalm: install instructions are incorrect. But changing So I tied the version of a guy who claims he fixed the plugin finding a few months ago ❯ asdf plugin remove alias
❯ asdf plugin add alias https://github.com/jtzero/asdf-alias.git
❯ asdf alias java 11.0 adoptopenjdk-11.0
asdf alias: The plugin 'java' could not be found This doesn't look promising. Is it worth looking into or should I go back to my original plan? |
There's asdf-vm/asdf#523 about aliases in asdf-core that should take a look, there are some insightful discussion about this problem. We had some aliases in other plugins but is still very premature, if anything I would start with the discussion in asdf-core. About the plugin, I did tested it a while ago, maybe something got borked in between We could add the alias subcommand to asdf-java but the real question is if we should haha By now the only way of aliasing is manually symlinking-reshimming, using a subcommand plugin or plain shell aliases is the user's choice |
Hi, just chiming in, currently I'm using specific JDK builds and I'm doing the following. This would be nice if the $ curl -sLO https://download.java.net/java/early_access/loom/4/openjdk-17-loom+4-174_osx-x64_bin.tar.gz
$ mkdir -p openjdk-17-loom+4-174; tar --strip-components=4 -C openjdk-17-loom+4-174/ -xf openjdk-17-loom+4-174_osx-x64_bin.tar.gz jdk-17.jdk/Contents/Home
$ asdf reshim java $ curl -sLO https://download.java.net/java/early_access/lanai/3/openjdk-17-lanai+3-133_osx-x64_bin.tar.gz
$ mkdir -p openjdk-17-lanai+3-133; tar --strip-components=4 -C openjdk-17-lanai+3-133/ -xf openjdk-17-lanai+3-133_osx-x64_bin.tar.gz jdk-17.jdk/Contents/Home
$ asdf reshim java |
@augustobmoura found what was wrong with @bric3 not sure how easy this would be, it would only work if those remote versions contained the same directory structure/setup. The loom and lanai builds do seem to be "according to standard", but your example shows that you are doing something different depending on the external version you are downloading. That's hard to do in a standard plugin function. In this case using a different approach (the default approach used in this plugin) would work for both in the same way though. So I think this should be doable. Not making any promises though. |
@delgurth Here the only difference is the name of the JDK in asdf. Here the tedious and error-prone part is the I would have preferred to identify the version in a automated way ( |
what about this way instead of
|
For simplicity, it'd be nice to have that behavior similar to how
jenv shell 11
would work. Just use the java 11 that you have available. If you've got more than one, it should probably fail.It'd sure be nice to be able to use a
.java-version
with just 11 in it. As best as I can tell that won't work?I've got java stuff that just needs to run on some java 1.8. And other things that just need some java 11. So it'd be nice if it could pick a tool that is compatible with java 1.8 or java 11, without having to be explicit about the precise versions of JVM installed.
The text was updated successfully, but these errors were encountered: