On Fri, Mar 7, 2014 at 12:17 AM, Luke Daley <luke.da...@gradleware.com>wrote:
> > > 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? > > > Launchable - represents an entity that can trigger Gradle build or another activity. Tasks are launchable. Selectors are kind of alias to a set of tasks belonging to a project (sub-)tree. Then we will have BuildLauncher launcher = projectConnection.newBuild(); launcher.forLaunchables(...).run(); Of course Buildable is taken.
