RFP - eXist-db

[joewiz]

Checklist

• [x] The package I am requesting does not already exist on https://chocolatey.org/packages;
• [x] There is no open issue for this package;
• [x] The issue title starts 'RFP - ';
• [x] The download URL is public and not locked behind a paywall / login;

Package Details

Software project URL : https://exist-db.org Direct download URL for the software / installer : https://bintray.com/existdb/releases/exist/5.2.0/view Software summary / short description: A high-performance open source native XML database

Package Expectations

eXist requires Java 8+ but does not currently embed a Java runtime. The eXist community has struggled to ensure our Windows users are able to properly install Java before running eXist, in particular, since our Windows installer (IzPack) needs Java to be installed to run. We are excited about the possibility of using chocolatey to overcome this problem: ideally, we could declare a dependency on a Java version, and chocolatey would install it before installing eXist when a user enters, choco install exist-db. I can try creating a package, but I am new to chocolatey and not really a Windows user myself, so if anyone has any suggestions or would be interested in helping, I would be grateful and happy to provide any information that would be useful.

cc/ @djbpitt @wolfgangmm

[pauby]

@joewiz There many different types and version of Java now - which one(s) does exist-db support?

[joewiz]

@pauby Thank you for your question. For eXist-db, while Java 8+ is the minimum requirement, we recommend Java 11. We have tested a number of OpenJDK flavors and have had good results with AdoptOpenJDK, etc. I believe, for example, that a dependency on adoptopenjdk11 would suffice. I would be interested to know if the resulting installation sets the JAVA_HOME environment variable or if Chocolatey would supply our application with the destination directory of the JDK installed during the installation of eXist?

[joewiz]

@johanjanssen I see you're the maintainer of many of the OpenJDK packages on Chocolatey. I noticed you've taken slightly different approaches with https://github.com/johanjanssen/AdoptOpenJDKChocolateyPackages and https://github.com/johanjanssen/ChocolateyPackages. Am I correct that you're planning to move the packages in the former repository (which use the zip file distribution) to the latter one (which uses the msi distribution)? I ask, because I'm trying to decide which of the various OpenJDKs available in Chocolatey might be the best choice for our application to list as a dependency. Our current IzPack-based Windows installer needs Java installed to run and benefits from the JAVA_HOME variable being set. Do you have any suggestions about going with the packages in either of your two repositories? Thanks in advance.

cc/ @adamretter

[johanjanssen-sanoma]

@joewiz that's unfortunately not correct. OpenJDK doesn't provide MSI installers at this time. So I unfortunately cannot migrate from the ZIP files to the MSI installer.

I like the installers better, they are easier to maintain. Next to that there is less scripting, which means less errors. However the AdoptOpenJDK installer at the moment has the disadvantage that if you upgrade the machine reboots. It's not something I can change. See: https://github.com/AdoptOpenJDK/openjdk-installer/issues/133. However I mainly use AdoptOpenJDK myself.

Regarding using one of them as a dependency. I find it quite annoying if packages have a dependency on a specific Java package. If I already installed another Java package, I end up with two Java packages and the new one is automatically made the default one. Of course you can exclude the dependency, but if you forget that... For me it's also a bit strange, because there are so many Java builds nowadays, I believe people should have the freedom to pick one themselves. Actually some packages such as IDE's and Maven removed the dependency on Maven after my suggestion.

But of course it's up to you as the maintainer to choose what to do :). I definitely understand that it's sometimes a bit more user friendly. But I would clearly note in the description that it's possible to exclude a dependency. For instance with: choco install [package-name] -y -ignoreDependencies

If you have any more questions please let me know.

[pauby]

@joewiz

I would be interested to know if the resulting installation sets the JAVA_HOME environment variable or if Chocolatey would supply our application with the destination directory of the JDK installed during the installation of eXist?

Chocolatey doesn't set that specifically. That is down to the maintainer / package / software to do that.

I would agree with what @johanjanssen-sanoma said regarding Java dependencies. In the 'good ole days' there was one Java so if your package needed Java, you added the dependency. There are so many today that it's no longer a good user experience to depend on a particular flavour of Java unless your software specifically needs it.

As the maintainer you have the freedom to craft your package as you need to. However as moderators we will pas that back to you if your package doesn't need the particular flavour of Java you take a dependency on. If it doesn't matter what flavour you need, then the best way to do this is to specify it in the description. You may even want to add a check in the Chocolatey package scripts to check for it too.

[joewiz]

@johanjanssen-sanoma @pauby Thanks very much for your advice. We'll discuss this on our next community call and get back to you if it seems like Chocolatey can help reduce the pain/uncertainty of getting Java installed alongside our application. At the very least, I think Chocolatey users may benefit from having an eXist-db package, just as many Mac users use Homebrew to install eXist-db: https://github.com/Homebrew/homebrew-cask/blob/master/Casks/exist-db.rb.

[pauby]

@joewiz Where are we with this now?

[joewiz]

@pauby Thanks for checking in! We weren't able to get to this item on last Monday's community call, but we will tomorrow.

[joewiz]

@pauby During today's eXist Community Call, we discussed Chocolatey, and we think that a Chocolatey package would be a benefit for Windows users who would like to install eXist. According to @reinhapa, AdoptOpenJDK does distribute MSI installers for all but the non-LTS versions, such as 9, etc., so @johanjanssen-sanoma, if you prefer MSI installers, AdoptOpenJDK has them. According to @adamretter, Java 11 would be the best bet for a Java dependency for eXist. Taken together, we'd recommend that the Chocolatey package declare AdoptOpenJDK 11 as its one and only dependency.

Thus, would it be possible to request help creating an eXist-db package with the parameters described above, with the following additional details?

1. eXist installation via jar, using the installation steps outlined at https://exist-db.org/exist/apps/doc/basic-installation#installation (see also https://exist-db.org/exist/apps/doc/advanced-installation for more detail on headless installation).
2. Dependency on AdoptOpenJDK 11

We (especially @wolfgangmm and I) would be happy to answer any questions, based on our experience helping Windows users install eXist-db.

We would be grateful for your assistance!

[johanjanssen-sanoma]

@johanjanssen-sanoma, if you prefer MSI installers, AdoptOpenJDK has them.

I know, I'm already using them for the AdoptOpenJDK Chocolatey package :).

I still think that you shouldn't depend on a specific Java build. However if you decide to do that, then please seriously consider depending on a JRE instead of a JDK. For AdoptOpenJDK 11 the JRE MSI is 130 MB smaller then the JDK. I provide packages for JRE's as well, see for instance https://chocolatey.org/packages/adoptopenjdk11jre

[pauby]

@joewiz Awesome this is moving forward.

I'm in agreement with @johanjanssen-sanoma though - if you don't need AdoptOpenJDK then I wouldn't take a dependency on it. It's not a good user experience to have to download a different flavour of Java because the author prefers it. If you require it then that is different. And I'm not talking about the version, just the flavour.

Part of what makes a good package manager is being able to take those dependencies and break them into other packages so they can be reused. AdoptOpenJDK is a good example of that. But it only works when you take dependencies you need to.

So the question is does eXist-db need a particular flavour of Java?

The debate over the JRE vs. JDK I will leave you guys to fight out 😸

[adamretter]

@pauby eXist-db needs a JRE which is at least Java 8. Maximum supported JRE is Java 11 for eXist-db. Is there a way to specify that generically?

[pauby]

@adamretter There isn't a way to specify a particular version of Java. There is a way to specify a particular version of a package. But no way to allow it to say 'at least one of these Java flavours at this version'.

Given this I would propose:

1. The description of the package is updated to clarify the situation with the Java flavour and version (ie. you clarify what flavours will / will not work and what the minimum version is);
2. You remove the dependency on AdoptOpenJDK as it's not required.

Does that make sense?

[adamretter]

You remove the dependency on AdoptOpenJDK as it's not required.

@pauby hmmm.. I don't think that is necessarily a good idea. Our application requires Java, without it, nothing will work. I would have thought/hoped that Choclatey would offer a "java-8-jre" metapackage which could be fulfilled by various implementation packages (e.g. Oracle, AdoptOpenJDK, etc), but would use a reasonable default if not already installed. I have seen this in other package systems like Apt/Deb

[pauby]

@adamretter We have other packages whose software requires Java (any flavour, particular version) and the description is updated to reflect this and code is sometimes added to the chocolateyInstall.ps1 file to check for it. That's a maintainers decision in the package.

If the moderator spots your dependency on a particular flavour of Java and it's not required, then it is unlikely to pass through moderation until it's removed. I wouldn't pass it.

We're aiming for a good user experience here. If I have a flavour of Java installed already, I don't want you requiring I download and install AdoptOpenJDK if it's not necessary.

I would have thought/hoped that Choclatey would offer a "java-8-jre" metapackage which could be fulfilled by various implementation packages (e.g. Oracle, AdoptOpenJDK, etc), but would use a reasonable default if not already installed.

Chocolatey and Nuget does have the concept of meta packages but they don't resolve the issue you have.

[adamretter]

So our package should not depend on Java?

We're aiming for a good user experience here.

I don't understand how it can be a "good user experience" if someone installs our package and it doesn't work because Java is not installed?

[joewiz]

I should note that homebrew's eXist recipe doesn't cause java to be installed either - it only lets users know that they need to and tells them how, via the "Caveats" directive:

==> Caveats exist-db requires Java 8+. You can install the latest version with: brew cask install adoptopenjdk

You can see this with brew cask info exist-db. This comes from https://github.com/Homebrew/homebrew-cask/blob/master/Casks/exist-db.rb#L15-L16. See also https://github.com/Homebrew/homebrew-cask/blob/master/doc/cask_language_reference/stanzas/caveats.md.

This sounds roughly analogous to what @pauby is describing above:

The description of the package is updated to clarify the situation with the Java flavour and version

[pauby]

@adamretter

So our package should not depend on Java?

That's not what I said. I said that your package should not have a dependency on a particular flavour if it's not an actual requirement. You've already confirmed that a specific flavour of Java is not required. Just a minimum version.

I don't understand how it can be a "good user experience" if someone installs our package and it doesn't work because Java is not installed?

That's why you would put notes in the description and add code to the chocolateyInstall.ps1 to let them know this and potentially fail to install if the minimum level of Java is not already installed.

As @joewiz has already said, this is no different to Homebrew.

[joewiz]

Thanks, everyone. I think we have agreement on the general parameters of the package:

• Package should install eXist via jar, using the installation steps outlined at https://exist-db.org/exist/apps/doc/basic-installation#installation (see also https://exist-db.org/exist/apps/doc/advanced-installation for more detail on headless installation).
• Package description should tell users that "eXist-db requires Java 8+." And possibly it could recommend the name of a package that supplies this requirement: "One such compatible version can be installed via: choco install adoptopenjdk11. Please make sure that this or another Java 8+ is installed before installing eXist-db."

If I'm summarizing this correctly, then would someone in the Chocolatey community consider drafting a package? I would be happy to test and report on how it works for me. Thanks in advance!

[pauby]

@joewiz I think those are sounds parameters for the package and I've opened this up to potential maintainers.

[djbpitt]

The most recent comment on this issue, from @pauby, is more than two years old, with upvotes from @joewiz and me. Is there anything at this stage that the chocolatey maintainers are looking for from the eXist-db side to move this along?

Copying @gabikeane and @EmmaSchwarz.

[pauby]

@djbpitt I think there is a little misunderstanding, so let me try and explain.

There is no group called 'chocolatey maintainers'. When we say 'maintainers' we're referring to anybody who wants to pick this package up and create it. That could be you, me, or anybody else. This repository exists as a list of packages that people have requested and a 'maintainer' can come along and say 'oh, I'll pick this one up and create a package for it'.

So this could sit here for two years or more until somebody comes along and does that.

There is a Chocolatey Community Chocolatey Packages and that is maintained by volunteer maintainers who manage the packages in there. There is also a process for moving an existing package in there for that group of volunteer maintainers to maintain (if they accept it).

Chocolatey doesn't create or maintain packages. So, there is no team at Chocolatey Software who would pick this up. Some of the Chocolatey Team maintain their own collection of packages, but that is done in their spare time.

Does that help?

[djbpitt]

@pauby Thank you, Paul. This information is helpful, since I hadn't known how Chocolatey was managed previously. I appreciate your having opened up the package for potential maintainers (you message of Feb 18, 2020, above), and since nobody has picked it up (fair enough), It sounds as if the likeliest way forward might now be for someone on the eXist-db side to take on the task of creating a Chocolatey package, and then for proposing it to Chocolatey Community Chocolatey Packages. I'll make inquiries in the eXist-db community to see whether there is someone who has the expertise to do that. I'm tagging @joewiz to keep him in the loop.

[pauby]

@djbpitt This does sound like the best course of action.

I wanted to draw your attention to the Chocolatey Community Chocolatey Packages repository. If the package is created in a way that it can be automatically updated, and it is accepted by the community team, they could migrate it over to that repository to have the community look after it.