In the package goal, the deployment (eg the WAR archive) is deployed in the provisioned server using the deploy management operation.

We realized that this breaks the WildFly operator transaction recovery that is mounting the standalone/data on a persistent volume[1].
Once solution would be to break down the standalone data dir to distinguish the various data that are store in this directory (tracked by WFCORE-6222). This would in turn brings issues with the migration of this directory when updating the server.

Another alternative is to keep the deployment in the standalone/deployments after the server is provisioned. This has the following advantages:

• It is the mechanism that was used by WildFly S2I images before the wildfly-maven-plugin was developed
• it removes any constraint on the standalone/data that can be mounted out of the application image
• it enables Docker layer optimization where we can have one layer for WildFly server bits and another layer for user bits
• it is mostly transparent from an user perspective

The disadvantages of this reversal are:

• if the deployment can not been deployed, it will fail when the container image is run instead of failing during the Maven package goal. In practice, this is not a big disadvantage as the `deploy` operation is run on a admin-only server and is only a subset of all the deployment steps
• the runtime-name option is only available on the deploy operation. We can repurpose this arguments to be able to change the name of the archive that we copy into the standalone/deployments.

[1] https://github.com/wildfly/wildfly-operator/issues/249