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
