search

johanjanssen / TemurinChocolateyPackages

Apache License 2.0
3 stars 4 forks source link

(adoptopenjdk) Using the new API v3, package parameters, and no more blank variables #6

Closed RedBaron2 closed 4 years ago

RedBaron2 commented 4 years ago

@johanjanssen @johanjanssen-sanoma This will use the newest API from AdoptOpenJDK requested in issue #5 . The update function can be used to update vendor openjdk/adoptopenjdk (upgradable in the future). This PR also allows for package parameters a requested feature from issue #3 , and also fixes issue #2 . This will also fix the issue #4 with the versioning from the previous script.

Tested in AppVeyor and locally. Un/Install work without and problems. Readme file is generated per package at time of update. Blank files may need to be created in Travis (have not tested, but are needed for AppVeyor). Updated package to have a icon file.

johanjanssen commented 4 years ago

Thanks a lot @RedBaron2 for all the hard work!

I've been looking into it, did some testing and had a few questions/remarks:

Let me know what you think of my remarks, I'm more then willing to help on those. But I don't want to change your setup without first agreeing on it :).

Again thank you very much it's a major step forward and helps me a lot!

RedBaron2 commented 4 years ago

@johanjanssen @johanjanssen-sanoma

  • Package names differ from the already existing packages. For instance AdoptOpenJDK-jdk14-openj9 vs adoptopenjdk14openj9. This would introduce all kinds of new packages, I think it's best to stick to the original names?

The option for using the dev_name is still an option with the new function. I have fixed this with the latest edit.

  • In the old script the 'versionless' package was updated with the latest version. So for instance the package adoptopenjdkjre is always created with the latest version of the AdoptOpenJDK JRE (now version 14). I think that functionality is now missing?

This is now fixed with the latest update

  • I think we can skip functionalities/workarounds for Java 9, 10, 12 as those won't get new releases

This is now fixed with the latest update

  • Is there a reason the early access releases are in there, do you want/need them? I don't know if they will be used and (almost) every new version of a package needs approval from the Chocolatey maintainers. Now it already can take a month to get an approval. The more releases we do, the longer it will take.

The pre releases would not be this long I would hope. It also requires new un/install files. These can be added later. If you want to go that route.

  • For the streams it might be better to use loops like in the old solution? So when a new Java version is released, it's only a matter of adding one value instead of 4 rows.

Fixed with the latest update

  • The packageargs in install32 and install64 are now filed by default with for instance "AdoptOpenJDK-jre8". Can't we leave them empty? Just a minor thing, but at first sight I thought Java 8 was hardcoded in the scripts :).

Yes, Oversight on my part. I have since blanked them out.

Let me know what you think of my remarks, I'm more then willing to help on those. But I don't want to change your setup without first agreeing on it :).

Again thank you very much it's a major step forward and helps me a lot!

I'm glad to help you out. I did see a minor problem with the latest version of the jdk/jre version 8 has a version that is 8.242.8 instead of the 8.0.242.8 that it should and will be with the latest script. It seems the problem was introduced back in the build released for Monday, March 4, 2019 It will be a problem in the future. Considering the long term release cycle for 8 builds.

I easiest solution I can think of is to un-list the last six packages on chocolatey, and then release the latest with the correct version number.

johanjanssen commented 4 years ago

I'm glad to help you out. I did see a minor problem with the latest version of the jdk/jre version 8 has a version that is 8.242.8 instead of the 8.0.242.8 that it should and will be with the latest script. It seems the problem was introduced back in the build released for Monday, March 4, 2019 It will be a problem in the future. Considering the long term release cycle for 8 builds.

I easiest solution I can think of is to un-list the last six packages on chocolatey, and then release the latest with the correct version number.

@RedBaron2 Unfortunately Chocolatey doesn't unlist packages. Which I can understand as people might use a fixed version. So I think we have to work around that and keep the versioning without the "0" for the 8 releases, which means we need to use 8.242.8 instead of 8.0.242.8 :(.

Actually the issue was caused because a new major version of Java is released as x with buildnumber instead of x.0.0 with the buildnumer. After the first Chocolatey package with the buildnumber 8.something I couldn't got back to 8.0.something. See below for an example of the release first release of 13 and the second release 13.0.1.

jdk-13%2B33/OpenJDK13U-jdk_x64_windows_hotspot_13_33.msi jdk-13.0.1%2B9/OpenJDK13U-jdk_x64_windows_hotspot_13.0.1_9.msi

I didn't take that into account in the beginning. Later I added a fix in the script which added ".0.0" for a new major version. Did you take that into account in your new script as well? I couldn't find it quickly...

RedBaron2 commented 4 years ago

@johanjanssen-sanoma @johanjanssen

Unfortunately Chocolatey doesn't unlist packages. Which I can understand as people might use a fixed version. So I think we have to work around that and keep the versioning without the "0" for the 8 releases, which means we need to use 8.242.8 instead of 8.0.242.8 :(.

This is a shame that Chocolatey doesn't have a unlist feature for its packages. I will have to suggest it at some point. Since this is the problem I have made the fix for the 8 releases ONLY. This will fix the versioning to the Bad Version that is listed on Chocolatey Currently. I re-fixed the fix to add minor to the build number string ( Ex: 8.0.242.8 would be 8.0242.8 ). When this is run through Get-Version the preceding zeros are removed.

I didn't take that into account in the beginning. Later I added a fix in the script which added ".0.0" for a new major version. Did you take that into account in your new script as well? I couldn't find it quickly...

The new version uses the supplied SemVer version number from the API. This is then modified so that the missing "0" or "0.0" won't happen for versions in the future 🤞

johanjanssen commented 4 years ago

@RedBaron2 thanks again. I'll merge your changes and then try / test them this week when updates for Java 8, 11 and 13 are released.