On 24 February 2014 at 6:14:40 pm, 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). EntryPoint just doesn’t feel right. These things are more like requests to do something than actual things. Saying a Task is-a EntryPoint is tangling to me. There can be an entry point that represents a task, but I don’t think it’s fundamental to a task that it’s an entry point. Will continue to think on better names. 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). Depends how forward looking we want to be here. Long term “build this model” will be the only kind of action possible. In that case, everything request would be a kind of model address, or some kind of spec that matches parts of the model. We are probably too far away from this to start thinking in these terms though. I don’t love the names we have at the moment. Anyone have any suggestions for better names?