To be honest, I always liked the 'TaskSelector' that is-a 'EntryPoint'. Until I read your email and started thinking about it :)
Some suggestions: TaskName TaskPath RequestedTask RequestedAction RequestedOperation BuildAction BuildOperation BuildItem GradleAction If the current names stay as they are, I won't cry too much, though. They are not beautiful but at least very easy to grasp. Cheers! On Mon, Feb 24, 2014 at 9:14 AM, Adam Murdoch <adam.murd...@gradleware.com>wrote: > Hi, > > I'm looking for some suggestions for names for some concepts we're trying > to model in the tooling API (and elsewhere). > > On the command-line, you can specify a bunch of things that you want > Gradle to do. There are 3 kinds of things you can provide: > > 1. A qualified path, which means 'run the task with the given path'. > 2. An unqualified name, which means 'run any task with the given name in > the current project and all its sub-projects'. > 3. Nothing, which means 'do some default stuff'. > > In the tooling API: > > For #1, we model this as a `Task`. If you give us a `Task` instance and > say 'run this' then we run the corresponding task. > > For #2, we've called this a 'task selector'. If you give us a > `TaskSelector` instance and say 'run this' then we run the corresponding > tasks. > > For #3, we haven't modelled this, but in theory we could to make this > explicit. > > Then, we have an abstract concept that represents these kinds of things. > Currently we've called this an 'entry point'. So, a `Task` is-a > `EntryPoint` and a `TaskSelector` is-a `EntryPoint`. For example, we have a > method that accepts a sequence of `EntryPoint` instances. This is > equivalent to providing the same entry points on the command-line (but > somewhat more flexible). > > The idea is that an 'entry point' represents some action that Gradle can > perform with the build. At the moment, this involves specifying some tasks, > but that won't necessarily always be the case (e.g. 'validate the model for > this project' might be an entry point that does not have a corresponding > task) or may imply a task or tasks only indirectly (e.g. 'run this test > class' or 'build this native library' will end up running some tasks but > the client has not named them explicitly at all). > > I don't love the names we have at the moment. Anyone have any suggestions > for better names? > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > > > -- Szczepan Faber Principal engineer@gradle; Founder@mockito
