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?
To be honest, I always liked the 'TaskSelector' that is-a 'EntryPoint'. Until I read your email and started thinking about it :)
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.
On Mon, Feb 24, 2014 at 9:14 AM, Adam Murdoch <[hidden email]> wrote:
Principal engineer@gradle; Founder@mockito
In reply to this post by Adam Murdoch
On 24 February 2014 at 6:14:40 pm, Adam Murdoch ([hidden email]) wrote:
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.
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.
On Fri, Mar 7, 2014 at 12:17 AM, Luke Daley <[hidden email]> wrote:
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.
In reply to this post by Luke Daley-2
On 7 Mar 2014, at 10:17 am, Luke Daley <[hidden email]> wrote:
True. At some point we may have tasks that are not entry points. Let’s detangle them.
I think so.
|Free forum by Nabble||Edit this page|