Consider Jib packaging type

We added a jib.skip property to deal with jib:build in a multi-module setup (#865 and #911). An alternative would be to create a custom jib packaging type that would incorporate one of our jib goals as part of the Maven lifecycle, and thus eliminate the need to explicitly invoke jib:*.

Creating a custom packaging is relatively straight-forward, and mapping to the maven-jar-plugin is pretty straightforward too. Except there’s a bit of a conflict in the default expectations of the package, install, and deploy lifecycle phases and effects of Jib build options: package is generally entirely local, install installs to local ~/.m2/repository, and deploy (upload somewhere). One possible mapping might be:

• package: buildTar
• install: dockerBuild ← load to the local docker daemon
• deploy: build

Another possibility is to introduce new Jib goals for install and deploy that load the built-tar container into the local docker daemon or upload to a registry.

Or another alternative is to define a single new Jib goal used for package whose build action is determined by a property. Say jib:package which uses the jib.destination property that defines tar, daemon, or registry.

[tandeday]

As the goals usually are exclusive (you don’t want a tar, deploy to local docker and a registry in the same build) I think it would be better to provide clear instructions on how to bind to the Maven build cycle.

A thing that may be easy to do, is to have “buildTar” generate the docker image as the build artifact, which can then be pushed to a maven registry and treated like any other artifact. This may be an interesting alternative to moving images around for existing Java pipelines.

[loosebazooka]

I think we are going to shelve this for now. Users wanting to integrate into the maven lifecycle can do so in their pom, disable the deploy and install tasks.