modelling build invocation in the tooling api

[Adam Murdoch]

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-2]

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 <[hidden email]> 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

[Luke Daley-2]

On 24 February 2014 at 6:14:40 pm, Adam Murdoch ([hidden email]) 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?

[Radim Kubacki]

On Fri, Mar 7, 2014 at 12:17 AM, Luke Daley <[hidden email]> wrote:

On 24 February 2014 at 6:14:40 pm, Adam Murdoch ([hidden email]) 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.

[Adam Murdoch]

On 7 Mar 2014, at 10:17 am, Luke Daley <[hidden email]> wrote:

On 24 February 2014 at 6:14:40 pm, Adam Murdoch ([hidden email]) 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