On 7 Mar 2014, at 10: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. > True. At some point we may have tasks that are not entry points. Let’s detangle them. > 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 think so. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
