The future of conventionMapping?

Help/Discuss
1

conventionMapping is an internal API that are used in a number of plugins. IIRC someone mentioned that conventionMapping are deprecated. Also I believe in the same context it was said that plugin authors should rather use extension objects,

Thus some questions:

  1. What is the roadmap to conventionMapping? Deprecated or going public?
  2. What is the recommendation we should give to plugin authors to use instead (if it is deprecated)?
  3. Are there use-cases where afterEvaluate could be a viable alternative?
2

Technically since it’s internal we would probably not deprecate it, rather we would likely remove it or replace it with something else. That said, there are currently no plans to do either since it’s used extensively in Gradle core.

There’s really not a good alternative. Model rules would be the recommended approach going forward but there is still a bit to do before many plugins can migrate.

Using afterEvaluate is typically a viable alternative in most every use case. That said, it’s not quite as good as convention mappings because technically further configuration could still be done in a subsequent afterEvaluate closure or worse, by a task at execution time. Convention mappings are evaluated when read (typically in the task action) so they are more likely to be correct.

In summary, feel free to use convention mappings (despite it being an internal feature). It’s not going anywhere anytime soon and is in many cases the best option for plugin authors.

1 Like
3

Thanks @mark_vieira. I’ll probably have to do a little write-up about use conventionMapping.

4

There is a public API for this now in Gradle 4.0. See the docs for the PropertyState interface.

1 Like