On 30/07/2013, at 2:30 PM, Alex Ruiz <alr...@google.com> wrote:
> Adam, please find inlined responses:
>
> On Mon, Jul 29, 2013 at 6:19 PM, Adam Murdoch <adam.murd...@gradleware.com>
> wrote:
>
> On 29/07/2013, at 4:25 PM, Alex Ruiz <alr...@google.com> wrote:
>
>> Thanks, Adam. I've been looking into (and debugging) how the current API for
>> retrieving models work, to have a better understanding on how the API and
>> implementation of this new action would look like.
>>
>> Attila: This approach may also benefit your work on Netbeans. Please take a
>> look.
>>
>> This is what I have in mind, based on what I have done this weekend:
>>
>> - The action interface can be simple, and so far this is what I think about
>> its API:
>>
>> public interface ConsumerAction<T> extends Serializable {
>> T execute(Project project);
>> }
>>
>> where Project is a org.gradle.api.Project. My understanding is that by
>> having a Project we can do everything we need (through
>> Project#getService()).
>
> The action should accept something other than `org.gradle.api.Project`, for a
> few reasons:
>
> 1. `org.gradle.api.Project` is not version-independent. The entry point for
> the action should be a function of the client's tooling API version, not
> target Gradle version.
> 2. Some actions don't need a configured project. For example, an action may
> just be interested in the project hierarchy or the build environment. Or it
> may not be interested in the tasks of a project, or the dependencies of a
> project, or whatever. Instead, we need an interface that implies no
> configuration is done, except for that which is explicitly requested by the
> action.
> 3. It's not going to work well with decoupled project mode (e.g. parallel
> execution, configure on demand). This will become the default at some point.
> The plan there is that there will be no way to navigate from one project to
> another. Instead, we need an interface which provides access to the whole
> build, but in a way that allows things like parallel configuration and
> configuration on demand.
> 4. There's no opportunity to cache models. We'd have to cache the whole
> project model, which is unlikely to be possible any time soon.
>
> So, instead, I'd introduce a new 'invocation' API. The contract would be that
> we start with an empty model and execute the action. The action can then use
> the invocation API to access the things it needs and these would be populated
> on demand.
>
> There's probably 2 basic things the API would need to do:
>
> 1. Give me the set of all the projects in the build. This would return
> something like `GradleProject` minus the tasks. It implies that the settings
> script has been executed.
> 2. For a given project, give me the model of type M.
>
> Possibly the API might also allow tasks to be scheduled and executed as well,
> but that can happen later.
>
>>
>> - The tooling API can have this method in ProjectConnection:
>>
>> <T> ConsumerActionExecutor<T> execute(ConsumerAction<T> action);
>>
>> where ConsumerActionExecutor is:
>>
>> public interface ConsumerActionExecutor<T> extends LongRunningOperation {
>> T get();
>> }
>>
>> This API sort of follows the pattern of ProjectConnection#model(Class).
>
> This is good.
>
>>
>> From here, I'm looking on how to implement what goes in between
>> ProjectConnection#execute(ConsumerAction) and ConsumerActionExecutor#get().
>
> There are some pretty deep changes here. I have some time to help out at the
> moment if you'd like me to pick up some (or most) of this.
>
> It would be absolutely great if we could count on your help, for many
> reasons, including:
> - I feel that our approach is very specific to Android Studio, while you have
> the "big picture" on how custom actions can work in more general use cases
> (e.g. Invocation API)
> - We are short of time. We'd like to be able to use this new API in Gradle 1.8
> - You know the tooling API the best!
>
> At the same time, I understand that you have a busy schedule. I'd suggest if
> you could please provide a skeleton API (interfaces) and I can work my way
> implementing them. WDYT?
Sounds good. I'll get something together soon.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
