We don't have any knowledge of the URLs that are persisted for Spring Boot. This candidate is actually managed by the Spring team themselves. It would be best to notify them on their own bug tracker.
https://github.com/sdkman/sdkman-cli/issues/1221
Bug report Unable to install all Spring Boot 1.X versions. Seems to be an issue with the download repository
Perhaps change it to the following: https://repo.maven.apache.org/maven2/org/springframework/boot/spring-boot-cli/1.5.9.RELEASE/
instead of http://repo.spring.io/release/org/springframework/boot/spring-boot-cli/1.5.9.RELEASE/ (broken)
To reproduce
% sdk install springboot 1.5.22.RELEASE
Downloading: springboot 1.5.22.RELEASE
In progress...
-=O=# # # #
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of /Users/user/.sdkman/tmp/springboot-1.5.22.RELEASE.zip or
/Users/user/.sdkman/tmp/springboot-1.5.22.RELEASE.zip.zip, and cannot find /Users/user/.sdkman/tmp/springboot-1.5.22.RELEASE.zip.ZIP, period.
System info OSX 13.3.1 (a) (22E772610a)
% sdk version
SDKMAN!
script: 5.18.1
native: 0.2.2
% zsh --version
zsh 5.9 (x86_64-apple-darwin22.0)
Comment From: philwebb
Thanks for the report but I'm afraid Spring Boot 1.x is no longer supported. Please upgrade to a supported version.
Comment From: codeconsole
@philwebb then perhaps you should not list them as available in sdkman?
Comment From: codeconsole
Kind of a poor user experience to list them as an available version. It would seem a pretty simple fix to just update the repo location to Maven Central. Although 1.x is not supported, it is useful to make available as a tool for upgrading from.
================================================================================
Available Springboot Versions
================================================================================
3.1.3 2.5.12 2.2.3.RELEASE 1.5.6.RELEASE
3.1.2 2.5.11 2.2.2.RELEASE 1.5.5.RELEASE
3.1.1 2.5.10 2.2.1.RELEASE 1.5.4.RELEASE
3.1.0 2.5.9 2.2.0.RELEASE 1.5.3.RELEASE
3.0.10 2.5.8 2.1.18.RELEASE 1.5.2.RELEASE
3.0.9 2.5.7 2.1.16.RELEASE 1.5.1.RELEASE
3.0.8 2.5.6 2.1.15.RELEASE 1.4.7.RELEASE
3.0.7 2.5.5 2.1.14.RELEASE 1.4.6.RELEASE
3.0.6 2.5.4 2.1.13.RELEASE 1.4.5.RELEASE
3.0.4 2.5.3 2.1.12.RELEASE 1.4.4.RELEASE
3.0.3 2.5.2 2.1.11.RELEASE 1.4.3.RELEASE
3.0.2 2.5.1 2.1.10.RELEASE 1.4.2.RELEASE
3.0.1 2.5.0 2.1.9.RELEASE 1.4.1.RELEASE
3.0.0 2.4.13 2.1.8.RELEASE 1.4.0.RELEASE
2.7.15 2.4.12 2.1.7.RELEASE 1.3.8.RELEASE
2.7.14 2.4.11 2.1.6.RELEASE 1.3.7.RELEASE
> * 2.7.13 2.4.10 2.1.5.RELEASE 1.3.6.RELEASE
2.7.12 2.4.9 2.1.4.RELEASE 1.3.5.RELEASE
2.7.11 2.4.8 2.1.3.RELEASE 1.3.4.RELEASE
2.7.10 2.4.7 2.1.2.RELEASE 1.3.3.RELEASE
2.7.9 2.4.6 2.1.1.RELEASE 1.3.2.RELEASE
2.7.8 2.4.5 2.1.0.RELEASE 1.3.1.RELEASE
2.7.7 2.4.4 2.0.9.RELEASE 1.3.0.RELEASE
2.7.6 2.4.3 2.0.8.RELEASE 1.2.8.RELEASE
2.7.5 2.4.2 2.0.7.RELEASE 1.2.7.RELEASE
2.7.3 2.4.1 2.0.6.RELEASE 1.2.6.RELEASE
2.7.2 2.4.0 2.0.5.RELEASE 1.2.5.RELEASE
2.7.1 2.3.12.RELEASE 2.0.4.RELEASE 1.2.4.RELEASE
2.7.0 2.3.11.RELEASE 2.0.3.RELEASE 1.2.3.RELEASE
2.6.15 2.3.9.RELEASE 2.0.2.RELEASE 1.2.2.RELEASE
2.6.14 2.3.8.RELEASE 2.0.1.RELEASE 1.2.1.RELEASE
2.6.13 2.3.7.RELEASE 2.0.0.RELEASE 1.2.0.RELEASE
2.6.12 2.3.6.RELEASE 1.5.22.RELEASE 1.1.12.RELEASE
2.6.11 2.3.5.RELEASE 1.5.21.RELEASE 1.1.11.RELEASE
2.6.10 2.3.4.RELEASE 1.5.20.RELEASE 1.1.10.RELEASE
2.6.9 2.3.3.RELEASE 1.5.19.RELEASE 1.1.9.RELEASE
2.6.8 2.3.2.RELEASE 1.5.18.RELEASE 1.1.8.RELEASE
2.6.7 2.3.1.RELEASE 1.5.17.RELEASE 1.1.7.RELEASE
2.6.6 2.3.0.RELEASE 1.5.16.RELEASE 1.1.6.RELEASE
2.6.5 2.2.13.RELEASE 1.5.15.RELEASE 1.1.5.RELEASE
2.6.4 2.2.12.RELEASE 1.5.14.RELEASE 1.1.4.RELEASE
2.6.3 2.2.11.RELEASE 1.5.13.RELEASE 1.1.3.RELEASE
2.6.2 2.2.9.RELEASE 1.5.12.RELEASE 1.1.2.RELEASE
Comment From: philwebb
I agree that the experience isn't great and now that I'm back at a computer a took another look to see if we could fix the links. Unfortunately, we're stuck!
The reason the links no longer work is because permissions have changed on repo.spring.io (see this blog post for details). Unfortunately, we didn't start publishing the binary zip to Maven central until Spring Boot 2.4.3. If you look here you'll see the -bin.zip file that SDKMAN uses, but here it's missing.
We don't have an easy way to add additional files to Maven central for existing releases and it's hard to justify the time that would be needed to find another solution. Especially given that we don't want folks using such an old version anyway!
I'm sorry, but at this point your only option is to use a recent version or install the older CLI manually using the -full.jar file which we have always published.
Comment From: codeconsole
@philwebb Why do you have to use the zip? You can't just have sdkman use the tar.gz file?
Looks like this started with 1.3.7.RELEASE
You can then just remove anything < 1.3.7 from sdkman. Better to not have it available then to have a broken install. Broken installs lead to broken confidence in the framework.
Comment From: philwebb
Why do you have to use the zip? You can't just have sdkman use the tar.gz file?
That doesn't appear to work:
After updating to use a tar.gz file:
sdk install springboot 1.5.22.RELEASE
Downloading: springboot 1.5.22.RELEASE
In progress...
############################################################################################################################################################################################################################################ 100.0%
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of /Users/pwebb/sdkman/tmp/springboot-1.5.22.RELEASE.zip or
/Users/pwebb/sdkman/tmp/springboot-1.5.22.RELEASE.zip.zip, and cannot find /Users/pwebb/sdkman/tmp/springboot-1.5.22.RELEASE.zip.ZIP, period.
You can then just remove anything < 1.3.7 from sdkman
I'm not aware of an SDKMAN API for that. See https://sdkman.io/vendors
Broken installs lead to broken confidence in the framework
If I had an easy way to fix this I would, but at this point spending any more time trying to fix this doesn't feel productive. I'd rather spend my limited time working on issues in the versions that we do support.
Comment From: codeconsole
I agree, I don't think it is worth spinning wheels over, but I would like to see it cleaned up without wasting a lot of time.
I'll try and come up with a better solution and follow up sdkman. As of now we can put this on hold untill I find a viable/quick alternative to either fix or clear out the old versions.
Comment From: philwebb
We discussed this again today as a team and we want to look to see if we can attach the CLI bin to the GitHub release and then update SDKMAN.
Comment From: philwebb
This should now be fixed. All release point to Maven Central when possible or GitHub releases when not. New GitHub releases were needed for older versions where we only previously had tags.