AdoptOpenJDK --params not working

[bberberov]

Hello,

I tried using --params to do INSTALLLEVEL=3 with AdoptOpenJDK jdk8 hotspot 8.252.9 8.252.9. It does not seem to be working. The example on the page does not work either:

choco install AdoptOpenJDK8 --params="/ADDLOCAL=FeatureMain,FeatureEnvironment,FeatureJarFileRunWith,FeatureJavaHome INSTALLDIR=c:\Program Files\AdoptOpenJDK\ /quiet"

In the end, I used --installargs for INSTALLLEVEL=3, and that worked. So, can/should we use --params like the documentation says, or use --installargs in all cases; and the documentation should reflect this?!

[RedBaron2]

@bberberov I'm sorry that it didn't work for you. It appears in my haste that I forgot to include a / before InstallDir which should be like this params="/ADDLOCAL=FeatureMain,FeatureEnvironment,FeatureJarFileRunWith,FeatureJavaHome /INSTALLDIR=c:\Program Files\AdoptOpenJDK\ /quiet" It will get fixed for the next releases. Please try again with the params as I listed them above.

Just a FYI but all the params should have the / before them. It is a requirement for the chocolatey helper function Get-PackageParameters

[bberberov]

OK. Sorry it took a while to test; we're using the JDK in this configuration. This is exactly what I tried:

choco install adoptopenjdk8 --params="/INSTALLLEVEL=3"

This is the result I get:

When I do:

choco install adoptopenjdk8 --ia="INSTALLLEVEL=3"

I get what I need:

Is there a way to use --params in this case, or should I use --ia. I'm quite new to chocolatey. I was hoping that using --params lets me upgrade without having to specify the options again; not sure how that works?!

[RedBaron2]

@bberberov There seems to be some disconnect with what is being sent to the installer via the params, and with your help we could figure it out. If you could post a gist of the chocolatey install log file. It is located in the %programdata%\chocolatey\logs. The information in the logs are not sanitized of any personal information so you may need to do that yourself. I'll work on it further next week.

Installation of these chocolatey packages in upgrades should be fine after your first install*, but You can use the feature named useRememberedArgumentsForUpgrades but this feature is considered preview and is off by default.

• The AdoptopenJDK installers should detect the previous install parameters, but I'm unsure of this currently.

[RedBaron2]

@bberberov I was able to track down the issue in my regex that was causing the issue. I'm sorry for the problem, and I should have caught it in my testing. Thanks for bringing it to our attention.

@johanjanssen @johanjanssen-sanoma

[johanjanssen]

I've just merged them.

@RedBaron2 thanks a lot!

@bberberov feel free to test it if you want. I will release them as Chocolatey packages in July when the new AdoptOpenJDK updates are released.

[jansohn]

I've also run into this issue. Why is this not released now?

[RedBaron2]

@jansohn A temporary fix is to use the install arguments --ia="INTALLLEVEL=3” or whatever the switch should be. I'm sorry for the delay, and the params not working correctly. Thanks for reaching out about the issue.

[jansohn]

@RedBaron2 I managed to install it the way I want with

choco install AdoptOpenJDK11 --ia="ADDLOCAL=FeatureMain,FeatureEnvironment,FeatureJarFileRunWith,FeatureJavaHome /quiet"

but I still think this should be fixed now as others will run into this issue, too. A fix is available so IMHO it should be released so others don't lose time over this as well.

[johanjanssen]

Of course there are some reasons to create a new release now, but there are also some reasons why not to release this fix separately such as: The (non trusted) packages need to be approved by the Chocolatey reviewers. Last time I think that took more than 4 weeks, there is a huge amount of packages waiting for reviews.

Within five weeks a new (minor) version of Java is released. If the Chocolatey package with the old version isn't approved before that date then it's simply replaced by the Chocolatey package with the new version and all the work was for nothing.

If not necessary I try to prevent to add extra ones. In this case it would mean about 12 extra packages.

We also need to change our scripts or manually change the version for the fix.

This feature was only introduced since the last release. Before that it wasn't even available, so I assume not to many people are using it.

I will think about it, but since this issue is not blocking, I'm a bit hesitant.

[bberberov]

Thanks @RedBaron2, @johanjanssen. I'll test it when the new AdoptOpenJDK is released, and let you know. I looked at the patch and it vaguely makes sense to me. PowerShell is still to foreign for me to make patches.

[johanjanssen]

Last issue has been resolved by #9