I’d like to know what top level tasks are to be used by convention, like “build”, “check”, “assemble”, and others when I create my own project. One reason is that “build” is a good generic top level task name that makes sense to use, another reason is that I want to make things feel familiar to other Gradle users.
While some of the tasks come with plugins, and aren’t part of the core conventions, there still seem to be some sort of agreement, although it’s never (that I can find) made clear anywhere if that’s intentional, or how to extend them in the best way, or if I need to use other names to avoid collisions.
To me this is almost the biggest hurdle in figuring out how to best use Gradle. I can set up tasks, write my own plugins, and create complex builds already, and I’ve been building my project for six months now. But I still feel like I’m not really getting what is convention, and what just happens to be used in one plugin or other.
The tasks you mentioned are really the only “conventions” used across Gradle plugins. In fact, those tasks are added by a “base” plugin, which all other plugins in turn, apply. As far as what you name tasks created by your plugin, I would just attempt to make them reasonably unique. I honestly haven’t heard of any cases where folks ran into task name collisions across plugins.
OK, thanks. Is this “base” plugin documented somehow? The collisions show up when one tries to define a task with the same name, e.g. “build”, before or after applying plugin. Would you say the proper way to go about it is to have new plugins inherit/apply this base plugin, and add details as dependencies to the “convention” tasks?