Hi jamers, Cleaning up my mailbox, I stumbled on this subject. I was actually looking into how the docker images are currently created, in order to add one for my own (pure smtp relay) assembly.
Work needs to be done on that. I'll open a INFRA ticket to get the > permission. Commiter conducting the release process would need to build > & tag & push docker images. > I found the ticket at https://issues.apache.org/jira/browse/INFRA-21180 it has been processed by infra during the holiday period \o/ On a similar topic we need to work on Guice servers packaging. See > https://issues.apache.org/jira/browse/JAMES-3261, > https://github.com/apache/james-project/pull/221. JAMES-3261 states: As such, in order to promote guice servers adoption, we need to build a ZIP > distribution for them. This ZIP distribution would then be built upon the > release and easily uploaded on the website. [...] Docker distributions would then reuse this ZIP in order to build the > resulting image. Note that sample configuration will then be centralized to > the APP maven project. I don't really care about the zip distribution but I understand why it may make sense. I would like to argue for a different direction for the docker images though. In the same way the PR proposes to use the maven-assembly-plugin to build the zip distribution, I would like to use the maven jib plugin to build the corresponding images instead of the shell scripts currently used. Here are a few pro and cons: pros: - jib builds optimized docker images which are harder to achieve by hand using a dockerfile - using a maven plugins would make it easier to refactor the build. I spent a couple days on a spike to extract and group runnable assemblies, to make them more easily discoverable for people new to the codebase, I aborted the work when I started having to update the docker shell scripts manually so they would find the relocated and renamed artifacts... - it is slightly easier to automate (for instance publishing snapshot releases to docker hub) - it would avoid the current situation of out of date scripts: dockerfiles/packaging/guice/cassandra/package.sh references `dockerfiles/compilation/java-8` which doesn't exist in the project anymore (since the java-11 switch I assume) and yet it is the one mentioned in `Generating a package for James` (which makes me curious as how linagora packages its own docker files) cons: - it will most likely require duplicating some configuration (copying the sample files I guess) I wanted to bring this up before I spent any time working on it, I'll be happy to read your thoughts :) jean
