Add new "source" goal

[rhuss]

mvn docker:tar should do the same as a build but attach the docker.tar which is used for building as an artifact with classifier ('-docker' ?) to the build. This will be ideally bound to a lifecycle phase.

As alternative one could think also about a new Maven top-level packaging (like jar or war), but that would required a dedicated project for the docker build.

Not sure about the name, though:

• docker:tar
• docker:save
• docker:attach
• docker:install
• ...

[Gengar003]

This would be helpful.

I currently use the maven-assembly-plugin to ape this functionality in my builds (which are builds of Docker images with no Java application or library):

1. I use top-level packaging type "jar"
2. After the Docker image is built, the maven-assembly-plugin .tar.gz's up the files used to build it, and drops it (properly-named) in ./target
3. The deploy lifecycle phase properly publishes this to the right spot in Nexus.

However, this relies on a developer-level, not-enforceable-with-code convention that all source required to build the Docker image come from certain locations in the project, which both the docker-maven-plugin and maven-assembly-plugin must look at.

If a developer broke this convention and only updated one of the plugins to know about it, the build would not detect this and would complete successfully, but the published Docker image would not be able to be recreated from the published .tar.gz.

If the docker-maven-plugin produced this .tar.gz instead, that would guarantee that the produced Docker image would be able to be recreated from the source artifact.

Naming

This is very similar in spirit to publishing the artifact-id-sources.jar alongside the artifact-id.jar by the maven-sources-plugin for traditional Maven/Java builds.

I therefore suggest docker:sources

[rhuss]

Yeah, docker:sources (or docker:source) sounds fine. Still not sure about singular vs. plural ;-)

[rhuss]

I pushed a snapshot 0.13.7-SNAPSHOT which has a goal docker:source for attaching docker tars with a classifier docker-<alias> (e.g. docker-service if the image has an alias has an alias service)

Not right sure whether this feels right, however since multiple builds can be attached per pom.xml there must be a way to either calculate the classifier from a unique build configuration datum or needs to be specified explicitly . Maybe its better do have a dedicated build config option 'classifier' ? Either as a mandatory option for docker:source or with a fallback of docker-<alias>.

I think I go for the fallback solution since at least having the possibility to explicitly specify a classifier might make sense.

Also maybe a skipSource flag would be good for omitting certain <build> from being attached. Currently we have skip in the build section which could be used in the execution binding configurations but that is maybe unnecessarily complicated ?