java-microprofile: what server config artifacts should be copied into the deployment image?

[scottkurz]

Summary

The current appsody build builds the entire target server config directory into the Docker image, via:

mv wlp/usr/servers/*/* /config/

On the other hand, the updated "getting started" guide only copies the src config directory, using:

COPY --chown=1001:0 src/main/liberty/config/ /config/
COPY --chown=1001:0 target/*.war /config/apps/

ADVANTAGES / DISADVANTAGES

By copying the target server config dir, we allow any config generation/merge done by the liberty-maven-plugin to take effect. E.g. the merge of POM properties, plugin config (inline and pointing to external files), -Dx=y..

By copying the server config contents from src, we avoid an issue like:
#516
where a "local dev" config artifact like server.env gets built into the image, though it shouldn't.

As the resolution of #516 shows, a solution here is to use appsody commands to structure your local dev (appsody run/test/debug) differently. But we still have to decide if this should be the user's responsibility.

---

Finally, I'm not sure what the overlap is precisely yet, but the issue #364 is also relevant.

[yeekangc]

Define and describe plus document what artifacts are expected where too. For example, dependency jars as noted in kabanero-io/docs#181.

[nastacio]

<Deleted my comment from 30 minutes ago as it was not making the problem clear. I am still rewording it for clarity and collecting more precise path collections for the examples.>

[scottkurz]

Though this issue hasn't been solved in the java-microprofile stack, relabeling to the java-openliberty stack, which is where we will prioritize a solution.

[scottkurz]

While it would require some design and discussion to get consensus on including some but not other entries with the target Open Liberty install, as long as we continue just copying everything (what we are doing today), then there's not much value in keeping this issue open. Closing.