autodeploy problems

[duncdrum]

What is the problem

The contents of the autodeploy directory are installed in alphabetical sequence. This is not great, it means that transient dependency resolution only works when the xar file name of the dependent app happens to be alphabetically greater than that of the dependency. Not to speak of locality variances in alphabetical sorting rules.
It also means that proper semantic versioning which is the norm for all default apps in autodeploy is not having the desired effects. As later sem-ver can be alphabetically earlier, and vice-versa.

What did you expect

Proper dependency handling, the name of the files shouldn't matter. If both packages are in the autodeploy folder installation should succeed
Where multiple versions of the same package are in the folder the latest compatible version should be installed

Describe how to reproduce or add a test

Copy two apps into autodeploy with a shared dependency. Z.xar and a.xar where a depends on z. a won't be available since at the time of its installaton, z was not yet installed and cannot be resolved.

To solve this we would need two things:

• A scan for declared dependencies that establishes installation sequence
• Replace the file-name based parsing with proper sem-ver parsing.

Context information

Please always add the following information

• eXist-db version any since 3.6.0 probably earlier
• Java version (e.g. Java8u121)
• Operating system any
• How is eXist-db installed? n.a.

[adamretter]

Sadly, this has been the case for as long as I can remember.

We planned to solve this as part of our EXPath Pkg 2.0 paper for Balisage... unfortunately that won't happen now, maybe by Prague 2020.

[duncdrum]

In the meantime, we could just tighten (and document) the rules for what happens in autodeploy. We can regex match filenames, to follow the de facto pattern of $name-$semver.xar and parse them accordingly.
As for the install and deploy into db, I was thinking of a simple check early during processing. If a xar has a declared dependency, check if its already in db (same what happens now), then if its not there check the contents of autodeploy for a file name that matches the same pattern as above. If its there, abort current operation and install and deploy said file. Obviously an install queue would be nicer, but then again we shouldn't let the perfect be the enemy of the good.

[line-o]

+1 for install queue