It seems when you start up Enonic XP, it will use the build which is stored in the blob, rather than the one in the file system. A workaround for it is simply touch the jar files in deploy after Enonic XP is finished starting up. (or you could do a full clean build deploy)
On my development laptop this is not much of a problem, but in QA and production, this could potentially break the website whenever a cluster node is restarted.
We can workaround that to by removing all jar files from $XP_HOME/deploy/ and always use toolbox install-app to install apps.
But if Enonic XP will continue to support watching the $XP_HOME/deploy/ folder, this bug needs to be fixed.
How does Enonic XP choose the newest build anyway? We might have several versions of an app in the $XP_HOME/deploy/ folder…
It might not be the older version in the blob store. It turns out I also had an older version of the jar file in the $XP_HOME/deploy/ folder, just with the old default “website” name, rather than the new “posten” filename.
Either way Enonic XP managed to pick an older build, rather than the newest.
Local/Blobstore app:
As you said in your third comment, this old app was this other jar “website” in your deploy folder and not an app from the blob store
An application present in the deploy folder will always override the one in the blob store (even at startup).
Versions:
But about the version. There is, for the moment, no management of version of application and rollback. But I will forward your request.
For the blobstore apps, it simply overrides when you install/update.
For local apps, it overrides also when you deploy an app. At startup it simply goes alphabetically through the list of jars (That is why it was working before but you had a problem when you renamed website to posten).
You should not have multiple jars for a same application in the deploy folder. It was never intended (see also next point).
QA/Production:
The use of the deploy folder is intended for development or debug.
We recommend using the classic “Applications” admin tool or the “install-app” of the toolbox as you mentionned. Especially if you are working with a cluster. (With blobstore apps, you are sure that all the nodes have the same applications and with the same version).
I notice now that the documentation does not describe these concepts. We will update it to provide more information.
I have updated our deploy scripts to use toolbox install-app in every environment.
I have also deleted all the apps in the deploy folder.
I keep all the builds (with a timestamp in their name) in a seperate folder, on nfs, so I can deploy/rollback using install-app on any cluster node.