Unification of docker-maven-plugin and fabric8-maven-plugin

[rhuss]

The fabric8-maven-plugin is quite similar to this plugin. This plugins manage all facets for integrating Docker in the Maven build cycle. fabric8-maven-plugin does the same for Kubernetes and OpenShift and relies on docker-maven-plugin for generating the images.

There is quite some overlap in configuration (guess it's around 80%) and since I'm working with both, I believe its a good idea to combine both. Unfortunately it is not possible to share configuration between plugins. A unification will widen the scope of this combined plugin, yes, but it will make it also much more powerful. For example, if we add finally docker-compose support we could easily map docker compose to Kubernetes configuration. For people using Kubernetes with Maven this would be a big, big win.

But before I start, I'd like to collect some opinions on that. Do you see any drawbacks when combining these plugins ? Do you also think its a good idea ?

Fire at will :)

[jgangemi]

can you give an example of exactly where the overlap is and what structure you see this taking?

will it be possible to put kubernetes code in a separate jar and pull that dependency in if it's actually needed or is the plugin potentially about to grow a lot in size? :)

can we make it require java8? lambdas are nice :-)

[rhuss]

@jgangemi I'm just in the beginning, but the overlap is probably more for the run aspect, not so much for the build aspect.

E..g. this configuration is shared for creating Kubernetes templates for Services and ReplicationControllers:

• The image name (of course ;-)
• Ports exposed
• Environment variables when running
• Labels

.... (but see also this kubernetes reference)

The other idea is to externalize the Kubernetes-config generation stuff external to the plugin, based on a Docker docker-compose.yml, which also hold this information. In order to share this the d-m-p only must be able to use a compose config, which is on the roadmap anyway.

@jstrachan is there already an issue for the docker-compose story for the kubernetes plugin ? If not I could create one.

The main use case indeed is to reuse configuration and avoid config duplication (and if possible to reuse code, too, but this is secondary. UX has the highest priority). I think we are better off with this 'external' config approach because the user audience for d-m-p is quite different than for fabric8 (although the fabric8 users will need the d-m-p, too, for building images).

/wrt to Java 8: Yeah lambda would be nice, but I really believe we should be conservative and support Java 7 for using the plugin. I've not experience yet, but is it possible to use a Java-8 based maven plugin with mvn running under Java 7 ? If so, we could consider the switch, otherwise I wouldn't do it.

[jstrachan]

@rhuss don't think there's an issue yet.

I was thinking of experimenting a little bit (e.g. taking compose, add pods somehow then extending the format to include stuff for services/SAs/ReplicationControllers/DeploymentControllers et al.

From a Java perspective I wonder if we need the option to have mvn post-process it and implement some property resolving (so the pom.xml could have some versions in it maybe?) Not sure how useful that would be yet ;)

I was wondering if we should bring this up in the kubernetes community as a whole as having a single compose like yml that can help developers define what they need in a simple concise way would be a big win really (with sensible smart defaults for most things; so generally things just work with little effort)

[OndraZizka]

Hi, what's the current state of docker-maven-plugin vs fabric8-maven-plugin? Am I supposed to use both? I know the DMP, starting with FMP. From the first look it seems I could replace DMP with FMP entirely, right?

[OndraZizka]

Also what about Jenkins X. Will it be integrated with either of these? We are just building a pipeline in our company and I wonder whether it would be worth waiting a bit and starting with JenkinsX rather than rewriting later.

[OndraZizka]

I have found: https://maven.fabric8.io/#generators

Since fabric8-maven-plugin includes docker-maven-plugin the way by which images are built is identical. Does that mean that swapping DMP with FMP is supposed to work without any further effort?

[rhuss]

This issue is quite old and a lot of things have happened in the meantime. The current status is:

• I have no ideas about Jenkins X and as it uses an orthogonal approach there will be no overlap
• d-m-p already went into f-m-p and is used for all plain Docker builds (but not s2i builds)
• The generator framework is still f-m-p only but it is planned to adopt it for d-m-p, too.
• The general vision is outlined in https://github.com/fabric8io/fabric8-build for a possible future of d-m-p and f-m-p

[OndraZizka]

Thanks @rhuss . Still not clear to me. Does the FMP cover all functionality of DMP? In other words, does DMP do something that FMP can't?

[rhuss]

Yes, there is a difference:

• f-m-p only exposes the "build" goal from d-m-p, nothing about "run" or any other goals.
• f-m-p adds OpenShift s2i capabilitites to the build, which are not available in d-m-p