afterEvaluate lifecycle events in plugins that load other plugins

I maintain two plugins that are loosely related, and would like to add a third that applies both and wires the configuration from one into the other to reduce the amount of boilerplate users of these plugins need to apply. These plugins are:

  • a distribution packager
  • a docker container builder

I’d like to specify a default Dockerfile that will use some information from the distribution plugin and then wire in the correct parameters for the docker container builder plugin.

It’s straightforward enough to cause this third plugin to apply the other two and read information out of their extensions/write information into their extensions, but I’m hitting a cryptic problem where the afterEvaluate event for the docker plugin is being fired at the end of the new plugin’s definition phase, rather than after the full configuration phase of the project.

The docker plugin uses afterEvaluate for two purposes:

  1. to validate the extension block is complete (and it’s not completely configured in the new plugin I’m writing)
  2. to generate extension-defined tasks, one for each tag for the docker image, for instance

I’m not sure what the best practice is for these two kinds of behaviors, and it’s possible I’m misusing afterEvaluate. So with that said, what’s the right way to compose these three plugins?

I own the three plugins here, so I’m happy to modify them to conform with best practices around use of extensions and definitions of custom tasks. The docs don’t seem to recommend a specific approach with how extension information is fed into tasks, and the maintainers of these plugins have differing opinions on how to feed extension information into the custom tasks. I’d also appreciate some discussion or thoughts on what’s considered idiomatic for extension/custom task relationship.

Dist plugin: https://github.com/palantir/sls-packaging
Docker plugin: https://github.com/palantir/gradle-docker

1 Like