Quantcast

Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

classic Classic list List threaded Threaded
110 messages Options
123456
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

kelemen
2013/7/30 Adam Murdoch [via Gradle] <[hidden email]>

On 29/07/2013, at 4:25 PM, Alex Ruiz <[hidden email]> 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.


It would be very convenient to have access to `org.gradle.api.Project` regardless. Not being version independent is not necessarily a problem, since Gradle has to maintain compatibility due to the build scripts and this compatibility should be enough. Actually, I could provide a lot better experience in NB if this was possible. For example, I could easily display all the source root with proper classpaths including the usual "integTest" sources.

Caching can be done external to Gradle. Actually, I already cache models. Also, there is no way to know in general if reevaluation of a project is necessary, so I believe that Gradle cannot do considerably better than an external process.

Anyway, I find the "invocation" API your are proposing a good general concept.
 
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.

Here a potential implementation plan:

1. Add the APIs and a dummy implementation that runs the action in the tooling API client and returns the result.
2. Pass the action across the cross-version layer into the provider. Move the dummy implementation into the provider.
3. Serialize the action across to the daemon and the result back. Move the dummy implementation into the daemon. Now we've got a round trip into the real process.
4. Add an initial implementation of the invocation API, which simply configures all projects before doing anything.
5. Handle the case where the result references one of the models returned by the invocation API.


Why is 5 a special case? Aren't they serializable already?
 
At this point, you've got a solution to your problem, as you can now do a single pass over the model and collect up the bits you need and send them back to the client. Later steps can make this better:

1. Don't configure a project until one of its models is requested.
2. Don't configure the project hierarchy until it is requested.
3. Don't configure the tasks of a project until they are requested

And generally making the invocation API richer.



I have created an initial draft for the required interfaces: https://gist.github.com/kelemen/6111321. See if you like it and what needs to modified, what is missing, or if it is completely wrong. Also, before actually executing this `ConsumerAction`, I need to know the version of Gradle if I can attempt to execute a `ConsumerAction` and fallback to what I do currently for versions older than 1.8. For which, it would be nice if there was a method to compare version numbers of Gradle.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

Adam Murdoch
In reply to this post by alex.ruiz.05

On 30/07/2013, at 2:30 PM, Alex Ruiz <[hidden email]> wrote:

Adam, please find inlined responses:

On Mon, Jul 29, 2013 at 6:19 PM, Adam Murdoch <[hidden email]> wrote:

On 29/07/2013, at 4:25 PM, Alex Ruiz <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

Adam Murdoch
In reply to this post by kelemen

On 30/07/2013, at 6:52 PM, kelemen <[hidden email]> wrote:

2013/7/30 Adam Murdoch [via Gradle] <<a href="x-msg://4953/user/SendEmail.jtp?type=node&amp;node=5711554&amp;i=0" target="_top" rel="nofollow" link="external">[hidden email]>

On 29/07/2013, at 4:25 PM, Alex Ruiz <[hidden email]> 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.


It would be very convenient to have access to `org.gradle.api.Project` regardless. Not being version independent is not necessarily a problem, since Gradle has to maintain compatibility due to the build scripts and this compatibility should be enough. Actually, I could provide a lot better experience in NB if this was possible. For example, I could easily display all the source root with proper classpaths including the usual "integTest" sources.

The process of importing Gradle into an IDE has to involve some kind of mapping. The Gradle model is much richer that the IDEs and this model has to be converted into the simpler model of each IDE. This mapping is lossy and as such the mapping needs to be flexible, and the build author and the various plugins must be able to have some influence over it. The mapping shouldn't be hardcoded in the IDE. This is one of the reasons the tooling API exists.

So, we have:

Gradle model -> transformation -> IDE model

It's a little more detailed than that:

Gradle DSL -> transformation -> canonical model -> transformation -> IDE model

That is, the user configures some stuff through the DSL, this is then converted to some internal model that various parts of Gradle use, including the IDE mapping. We keep the DSL backwards compatible, but we don't for the canonical model. We plan to, but we're not there yet.  In other words, the stuff you need from the project (i.e. the canonical model) is not backwards compatible at all.

So, rather than access `Project` directly, I'd much prefer if you help us grow the tooling API models instead. It's easy to add stuff once you know the pattern.

These models then form a contract, as they declare what you need from the model. We can keep this stable and make it faster over time. They also allow us to offer consistent behaviour across IDEs (which is important to us, possibly not so for you).



Caching can be done external to Gradle. Actually, I already cache models. Also, there is no way to know in general if reevaluation of a project is necessary, so I believe that Gradle cannot do considerably better than an external process.

There's an awful lot to track when checking for changes in the model. Here are some examples:

- Changes in the build script and in one of the ancestor's build scripts.
- Changes in the settings scripts.
- Changes in the init scripts passed as command-line args, or in ~/.gradle/init.gradle or ~/.gradle/init.d
- Changes in any local or remote scripts applied by any of the above or any init scripts bundled in the distributions.
- Changes in gradle.properties and ~/.gradle/gradle.properties.
- Changes to the Gradle version in gradle-wrapper.properties.
- Changes in the source or dependencies of buildSrc
- Changes in the classpath used at configuration time, eg local jars.
- Changes to dependencies in the remote repositories.
- Changes in the configuration files or remote resources that my custom plugin uses to configure the build.

You get the idea. It think good change detection has to be a collaboration between Gradle and the IDE.



Anyway, I find the "invocation" API your are proposing a good general concept.
 
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.

Here a potential implementation plan:

1. Add the APIs and a dummy implementation that runs the action in the tooling API client and returns the result.
2. Pass the action across the cross-version layer into the provider. Move the dummy implementation into the provider.
3. Serialize the action across to the daemon and the result back. Move the dummy implementation into the daemon. Now we've got a round trip into the real process.
4. Add an initial implementation of the invocation API, which simply configures all projects before doing anything.
5. Handle the case where the result references one of the models returned by the invocation API.


Why is 5 a special case? Aren't they serializable already?
 
At this point, you've got a solution to your problem, as you can now do a single pass over the model and collect up the bits you need and send them back to the client. Later steps can make this better:

1. Don't configure a project until one of its models is requested.
2. Don't configure the project hierarchy until it is requested.
3. Don't configure the tasks of a project until they are requested

And generally making the invocation API richer.



I have created an initial draft for the required interfaces: https://gist.github.com/kelemen/6111321. See if you like it and what needs to modified, what is missing, or if it is completely wrong. Also, before actually executing this `ConsumerAction`, I need to know the version of Gradle if I can attempt to execute a `ConsumerAction` and fallback to what I do currently for versions older than 1.8. For which, it would be nice if there was a method to compare version numbers of Gradle.


View this message in context: Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API
Sent from the gradle-dev mailing list archive at Nabble.com.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

kelemen
2013/8/1 Adam Murdoch [via Gradle] <[hidden email]>

On 30/07/2013, at 6:52 PM, kelemen <[hidden email]> wrote:

2013/7/30 Adam Murdoch [via Gradle] <<a href="x-msg://4953/user/SendEmail.jtp?type=node&amp;node=5711554&amp;i=0" target="_top" rel="nofollow" link="external">[hidden email]>


On 29/07/2013, at 4:25 PM, Alex Ruiz <[hidden email]> 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.


It would be very convenient to have access to `org.gradle.api.Project` regardless. Not being version independent is not necessarily a problem, since Gradle has to maintain compatibility due to the build scripts and this compatibility should be enough. Actually, I could provide a lot better experience in NB if this was possible. For example, I could easily display all the source root with proper classpaths including the usual "integTest" sources.

The process of importing Gradle into an IDE has to involve some kind of mapping. The Gradle model is much richer that the IDEs and this model has to be converted into the simpler model of each IDE. This mapping is lossy and as such the mapping needs to be flexible, and the build author and the various plugins must be able to have some influence over it. The mapping shouldn't be hardcoded in the IDE. This is one of the reasons the tooling API exists.

So, we have:

Gradle model -> transformation -> IDE model

It's a little more detailed than that:

Gradle DSL -> transformation -> canonical model -> transformation -> IDE model

That is, the user configures some stuff through the DSL, this is then converted to some internal model that various parts of Gradle use, including the IDE mapping. We keep the DSL backwards compatible, but we don't for the canonical model. We plan to, but we're not there yet.  In other words, the stuff you need from the project (i.e. the canonical model) is not backwards compatible at all.

So, rather than access `Project` directly, I'd much prefer if you help us grow the tooling API models instead. It's easy to add stuff once you know the pattern.

These models then form a contract, as they declare what you need from the model. We can keep this stable and make it faster over time. They also allow us to offer consistent behaviour across IDEs (which is important to us, possibly not so for you).


There might be some misundestanding between us, so I will try to clarify my assumptions and see where it differs from yours:

1. The proposed `ConsumerAction` runs in the same process where the project got evaluated, so I believe that the compatibility of the DSL is sufficient. For example: I should be able to iterate over the sourcesets because I can do so in the build script.

2. If projects are evaluated in multiple processes, then I'd prefer to design an API which works even in this case but still runs foreign (i.e., foreign to Gradle) code in the process where the project got evaluated (in multiple processes if necessary).

3. I assume that DSL compatibility implies that no methods or classes will disappear from the http://www.gradle.org/docs/current/javadoc/. I don't assume, that I can just implement interfaces (like `Project`).

4. I'm not sure what you mean by "canonical model". `Project` or something else? If it is the `Project`, then I don't understand because the build script can access it as well (see 3). If it is something else, then I don't need that one. I just need the `Project` instance right after the buildscript set it up. Of course, this limits the IDE integration (those using `Project`) in some marginal use-cases. But there are already limitations, I don't think an IDE integration should consider all extreme use cases. Build masters should be sane enough to write build scripts so that the IDE understands it. By the way, I already pass init scripts (optionally, opt-out) when running tasks which means that I already access `Project`.

5. I don't understand what you mean on consistent behaviour. There are still models like `EclipseProject` and `IdeaProject`. How does this help consistency? If you mean deprecating these models and adding common models like `JavaProjectModel`, `GroovyProjectModel` and whatever else, then this could mean an awful lot of models. Now, I may consider adding models to Gradle myself (although I already spend lots of my free time on coding other projects). However, assume that I go mad adding lots models, which you find quality enough to accept: Do you plan to support these models "forever" considering backward (or worse, forward) compatibility without me? You see, even though it could be my true intent to support them for you, I might die tomorrow. This is something you must consider. That is, Gradleware cannot truly rely on external contributons for these models.

6. Let's be rational: I mean no offense but considering the past, you spend a small portion of your resources for making models better. I believe that it is not rational to believe that the percentage of resources you can and will spend on adding new features to the model will be increased in the future. To be honest, I think you shouldn't change your current priorities too much because other things are very important as well.

So, given these, I wish to avoid Gradleware spending more resources on maintaining compatibility for the new models. I want you to push these maintaining work to IDE integration developers (like me). But you cannot do so by asking me to add new models (see 5) myself. If you want me to create models without pushing these models to the Gradle repo, then I don't see what is the gain. I still need to build that model somehow from `Project`.

What is the gain from accessing the `Project` through the Tooling API (as proposed by Alex and me)? In this case, I'm relieved from the burden of maintaining a backward (or forward) compatible model. Even if I screw up in a version, I can simply fix this in a patch and release a new version of the NB plugin independently of Gradle. Speaking of which, independent release from Gradle allows me to consider users needs and react to these needs on my own schedule. Also, different IDEs might have considerable different view of the world and I'm also pretty sure that users of different IDEs have different expectations on how things should be done (there is a reason for why they choose one IDE over another).

Saying all these, I'd prefer if developers of Idea and Eclipse integration would voice their opinion. Also, I believe you should wait for their opinion. That is, IDE integration developers are the main users of this API (at least, I believe this is where these new changes matter most).
 


Caching can be done external to Gradle. Actually, I already cache models. Also, there is no way to know in general if reevaluation of a project is necessary, so I believe that Gradle cannot do considerably better than an external process.

There's an awful lot to track when checking for changes in the model. Here are some examples:

- Changes in the build script and in one of the ancestor's build scripts.
- Changes in the settings scripts.
- Changes in the init scripts passed as command-line args, or in ~/.gradle/init.gradle or ~/.gradle/init.d
- Changes in any local or remote scripts applied by any of the above or any init scripts bundled in the distributions.
- Changes in gradle.properties and ~/.gradle/gradle.properties.
- Changes to the Gradle version in gradle-wrapper.properties.
- Changes in the source or dependencies of buildSrc
- Changes in the classpath used at configuration time, eg local jars.
- Changes to dependencies in the remote repositories.
- Changes in the configuration files or remote resources that my custom plugin uses to configure the build.

You get the idea. It think good change detection has to be a collaboration between Gradle and the IDE.



Knowing on what the build script depends is impossible. It can be a content of a directory or other things (an absurd example would be System.nanoTime % 2). Although it might be reasonable to expect the user not to depend on anything he or she whishes. However, I have never seen serious need for this automatic change detection. People seem to be content with manual reloading. Also, it might be even harmful to reload a model just because a build script or something else changes because the background work (what Gradle does) might interfere with the user (reading from the harddrive might slow down things) and actually, users don't really need the new model for every small changes. Like adding a println to a file in buildSrc is really not something to worry about.

Although in the past I thought similar to you, I now believe that this kind of caching is not something the users need. Caching which benefits the user is something different and it is important that the user may refresh at will (ignoring caching). I still need to implement persistent cache but I believe that this is not something you should spend effort on. At least not without explicitly polling the users need. But even if it turns that this is something important, allowing access to `Project` shouldn't cause a problem. Only that you won't cache `Project` instances, so anyone relying it won't automatically benefit from your caching. The implementor (and its users) then might choose if this is something worth losing the benefits of being able to access `Project`.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

Adam Murdoch
In reply to this post by alex.ruiz.05

On 30/07/2013, at 2:30 PM, Alex Ruiz <[hidden email]> wrote:

Adam, please find inlined responses:

On Mon, Jul 29, 2013 at 6:19 PM, Adam Murdoch <[hidden email]> wrote:

On 29/07/2013, at 4:25 PM, Alex Ruiz <[hidden email]> 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?

I've added a basic implementation. It's available in the latest nightly at http://www.gradle.org/nightly


Right now, the action can ask for multiple models via the BuildController passed to the action: http://www.gradle.org/docs/nightly/javadoc/org/gradle/tooling/BuildController.html

Let me know what else you need on this interface.

The implementation is pretty rough. Give it a try and let me know what breaks :)


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

alex.ruiz.05
Awesome!! Thanks a lot, Adam. I'll give a try and I'll you know how it goes.

Regards,
-Alex


On Thu, Aug 8, 2013 at 7:59 PM, Adam Murdoch <[hidden email]> wrote:

On 30/07/2013, at 2:30 PM, Alex Ruiz <[hidden email]> wrote:

Adam, please find inlined responses:

On Mon, Jul 29, 2013 at 6:19 PM, Adam Murdoch <[hidden email]> wrote:

On 29/07/2013, at 4:25 PM, Alex Ruiz <[hidden email]> 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?

I've added a basic implementation. It's available in the latest nightly at http://www.gradle.org/nightly


Right now, the action can ask for multiple models via the BuildController passed to the action: http://www.gradle.org/docs/nightly/javadoc/org/gradle/tooling/BuildController.html

Let me know what else you need on this interface.

The implementation is pretty rough. Give it a try and let me know what breaks :)



--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

kelemen
In reply to this post by Adam Murdoch
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

alex.ruiz.05
Hi Adam,

I tried the new API, and I got a ClassNotFoundException wrapped in a InvalidClassException. The class not found is private static class ActionAwareConsumerConnection$BuildActionAdapter.

I tried to solve the issue by making BuildActionAdapter a public top-level class (did a pull from Gradle's git repo,) but it didn't work. After some googling, I did not get anywhere :-(

Please find the stack trace at the bottom of the email.

Thank you,
-Alex

org.gradle.tooling.GradleConnectionException: Could not run build action using Gradle installation '/Users/alruiz/Downloads/gradle-1.8-20130811071946+0000'.
at org.gradle.tooling.internal.consumer.ResultHandlerAdapter.onFailure(ResultHandlerAdapter.java:59)
at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor$1$1.run(DefaultAsyncConsumerActionExecutor.java:57)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)
at org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46)
at org.gradle.tooling.internal.consumer.DefaultBuildActionExecuter.run(DefaultBuildActionExecuter.java:43)
at com.android.tools.idea.gradle.project.ProjectResolver2.resolveProjectInfo(ProjectResolver2.java:97)
at com.android.tools.idea.gradle.project.AndroidGradleProjectResolver$ProjectResolverFunctionFactory$1.fun(AndroidGradleProjectResolver.java:170)
at com.android.tools.idea.gradle.project.AndroidGradleProjectResolver$ProjectResolverFunctionFactory$1.fun(AndroidGradleProjectResolver.java:165)
at org.jetbrains.plugins.gradle.service.project.GradleExecutionHelper.execute(GradleExecutionHelper.java:109)
at com.android.tools.idea.gradle.project.AndroidGradleProjectResolver.resolveProjectInfo(AndroidGradleProjectResolver.java:104)
at com.android.tools.idea.gradle.project.AndroidGradleProjectResolver.resolveProjectInfo(AndroidGradleProjectResolver.java:55)
at org.jetbrains.plugins.gradle.service.project.GradleProjectResolver.resolveProjectInfo(GradleProjectResolver.java:81)
at org.jetbrains.plugins.gradle.service.project.GradleProjectResolver.resolveProjectInfo(GradleProjectResolver.java:46)
at com.intellij.openapi.externalSystem.service.remote.RemoteExternalSystemProjectResolverImpl$1.produce(RemoteExternalSystemProjectResolverImpl.java:41)
at com.intellij.openapi.externalSystem.service.remote.RemoteExternalSystemProjectResolverImpl$1.produce(RemoteExternalSystemProjectResolverImpl.java:37)
at com.intellij.openapi.externalSystem.service.remote.AbstractRemoteExternalSystemService.execute(AbstractRemoteExternalSystemService.java:59)
at com.intellij.openapi.externalSystem.service.remote.RemoteExternalSystemProjectResolverImpl.resolveProjectInfo(RemoteExternalSystemProjectResolverImpl.java:37)
at com.intellij.openapi.externalSystem.service.remote.wrapper.ExternalSystemProjectResolverWrapper.resolveProjectInfo(ExternalSystemProjectResolverWrapper.java:49)
at com.intellij.openapi.externalSystem.service.internal.ExternalSystemResolveProjectTask.doExecute(ExternalSystemResolveProjectTask.java:53)
at com.intellij.openapi.externalSystem.service.internal.AbstractExternalSystemTask.execute(AbstractExternalSystemTask.java:130)
at com.intellij.openapi.externalSystem.service.internal.AbstractExternalSystemTask.execute(AbstractExternalSystemTask.java:120)
at com.intellij.openapi.externalSystem.util.ExternalSystemUtil$3.execute(ExternalSystemUtil.java:388)
at com.intellij.openapi.externalSystem.util.ExternalSystemUtil$4$2.run(ExternalSystemUtil.java:435)
at com.intellij.openapi.progress.impl.ProgressManagerImpl$TaskRunnable.run(ProgressManagerImpl.java:465)
at com.intellij.openapi.progress.impl.ProgressManagerImpl$2.run(ProgressManagerImpl.java:175)
at com.intellij.openapi.progress.ProgressManager.executeProcessUnderProgress(ProgressManager.java:207)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:209)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.runProcess(ProgressManagerImpl.java:168)
at com.intellij.openapi.progress.impl.ProgressManagerImpl$8.run(ProgressManagerImpl.java:375)
at com.intellij.openapi.application.impl.ApplicationImpl$8.run(ApplicationImpl.java:434)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)
at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:151)
Caused by: org.gradle.internal.UncheckedException: java.io.InvalidClassException: failed to read class descriptor
at org.gradle.internal.UncheckedException.throwAsUncheckedException(UncheckedException.java:39)
at org.gradle.tooling.internal.provider.PayloadSerializer.doDeserialize(PayloadSerializer.java:196)
at org.gradle.tooling.internal.provider.PayloadSerializer.deserialize(PayloadSerializer.java:138)
at org.gradle.tooling.internal.provider.ClientProvidedBuildAction.run(ClientProvidedBuildAction.java:42)
at org.gradle.tooling.internal.provider.ClientProvidedBuildAction.run(ClientProvidedBuildAction.java:32)
at org.gradle.tooling.internal.provider.ConfiguringBuildAction.run(ConfiguringBuildAction.java:108)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:35)
at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:45)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:42)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:24)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.StartStopIfBuildAndStop.execute(StartStopIfBuildAndStop.java:33)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.ReturnResult.execute(ReturnResult.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:71)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:69)
at org.gradle.util.Swapper.swap(Swapper.java:38)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:69)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:60)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:59)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:45)
at org.gradle.launcher.daemon.server.DaemonStateCoordinator.runCommand(DaemonStateCoordinator.java:186)
at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy.doBuild(StartBuildOrRespondWithBusy.java:49)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.HandleStop.execute(HandleStop.java:36)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.CatchAndForwardDaemonFailure.execute(CatchAndForwardDaemonFailure.java:32)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.DefaultDaemonCommandExecuter.executeCommand(DefaultDaemonCommandExecuter.java:48)
at org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler$ConnectionWorker.handleCommand(DefaultIncomingConnectionHandler.java:155)
at org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler$ConnectionWorker.receiveAndHandleCommand(DefaultIncomingConnectionHandler.java:128)
at org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler$ConnectionWorker.run(DefaultIncomingConnectionHandler.java:116)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.io.InvalidClassException: failed to read class descriptor
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1580)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1494)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1748)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1327)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
at org.gradle.tooling.internal.provider.PayloadSerializer.doDeserialize(PayloadSerializer.java:194)
... 44 more
Caused by: java.lang.ClassNotFoundException: org.gradle.tooling.internal.consumer.connection.BuildActionAdapter
at org.gradle.internal.classloader.TransformingClassLoader.findClass(TransformingClassLoader.java:41)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:249)
at org.gradle.tooling.internal.provider.PayloadSerializer$2.readClass(PayloadSerializer.java:175)
at org.gradle.tooling.internal.provider.PayloadSerializer$2.readClassDescriptor(PayloadSerializer.java:159)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1578)
... 49 more


On Sat, Aug 10, 2013 at 11:35 AM, kelemen <[hidden email]> wrote:
The new API throws an exception for me. Here is the stacktrace:
https://gist.github.com/kelemen/6201595

And here is the code using the new API:
https://github.com/kelemen/netbeans-gradle-project/blob/d3a82f4f761fc6bf8ebcf75b00ae8da81f89ce58/src/main/java/org/netbeans/gradle/project/model/NbGradle18ModelLoader.java



--
View this message in context: http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711666.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

Adam Murdoch
In reply to this post by kelemen

I've added some diagnostics to the latest nightly build. Can you give this a try and send me the output. It's logged to System.out.

Also is there some way I can run your code to debug what's going on?

On 11/08/2013, at 4:35 AM, kelemen <[hidden email]> wrote:

The new API throws an exception for me. Here is the stacktrace:
https://gist.github.com/kelemen/6201595

And here is the code using the new API:
https://github.com/kelemen/netbeans-gradle-project/blob/d3a82f4f761fc6bf8ebcf75b00ae8da81f89ce58/src/main/java/org/netbeans/gradle/project/model/NbGradle18ModelLoader.java



--
View this message in context: http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711666.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

Adam Murdoch
In reply to this post by alex.ruiz.05

I've added some diagnostics to the latest nightly. Can you try this and send me the logging output (logged to System.out)?

On 11/08/2013, at 6:05 PM, Alex Ruiz <[hidden email]> wrote:

Hi Adam,

I tried the new API, and I got a ClassNotFoundException wrapped in a InvalidClassException. The class not found is private static class ActionAwareConsumerConnection$BuildActionAdapter.

I tried to solve the issue by making BuildActionAdapter a public top-level class (did a pull from Gradle's git repo,) but it didn't work. After some googling, I did not get anywhere :-(

Please find the stack trace at the bottom of the email.

Thank you,
-Alex

org.gradle.tooling.GradleConnectionException: Could not run build action using Gradle installation '/Users/alruiz/Downloads/gradle-1.8-20130811071946+0000'.
at org.gradle.tooling.internal.consumer.ResultHandlerAdapter.onFailure(ResultHandlerAdapter.java:59)
at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor$1$1.run(DefaultAsyncConsumerActionExecutor.java:57)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)
at org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46)
at org.gradle.tooling.internal.consumer.DefaultBuildActionExecuter.run(DefaultBuildActionExecuter.java:43)
at com.android.tools.idea.gradle.project.ProjectResolver2.resolveProjectInfo(ProjectResolver2.java:97)
at com.android.tools.idea.gradle.project.AndroidGradleProjectResolver$ProjectResolverFunctionFactory$1.fun(AndroidGradleProjectResolver.java:170)
at com.android.tools.idea.gradle.project.AndroidGradleProjectResolver$ProjectResolverFunctionFactory$1.fun(AndroidGradleProjectResolver.java:165)
at org.jetbrains.plugins.gradle.service.project.GradleExecutionHelper.execute(GradleExecutionHelper.java:109)
at com.android.tools.idea.gradle.project.AndroidGradleProjectResolver.resolveProjectInfo(AndroidGradleProjectResolver.java:104)
at com.android.tools.idea.gradle.project.AndroidGradleProjectResolver.resolveProjectInfo(AndroidGradleProjectResolver.java:55)
at org.jetbrains.plugins.gradle.service.project.GradleProjectResolver.resolveProjectInfo(GradleProjectResolver.java:81)
at org.jetbrains.plugins.gradle.service.project.GradleProjectResolver.resolveProjectInfo(GradleProjectResolver.java:46)
at com.intellij.openapi.externalSystem.service.remote.RemoteExternalSystemProjectResolverImpl$1.produce(RemoteExternalSystemProjectResolverImpl.java:41)
at com.intellij.openapi.externalSystem.service.remote.RemoteExternalSystemProjectResolverImpl$1.produce(RemoteExternalSystemProjectResolverImpl.java:37)
at com.intellij.openapi.externalSystem.service.remote.AbstractRemoteExternalSystemService.execute(AbstractRemoteExternalSystemService.java:59)
at com.intellij.openapi.externalSystem.service.remote.RemoteExternalSystemProjectResolverImpl.resolveProjectInfo(RemoteExternalSystemProjectResolverImpl.java:37)
at com.intellij.openapi.externalSystem.service.remote.wrapper.ExternalSystemProjectResolverWrapper.resolveProjectInfo(ExternalSystemProjectResolverWrapper.java:49)
at com.intellij.openapi.externalSystem.service.internal.ExternalSystemResolveProjectTask.doExecute(ExternalSystemResolveProjectTask.java:53)
at com.intellij.openapi.externalSystem.service.internal.AbstractExternalSystemTask.execute(AbstractExternalSystemTask.java:130)
at com.intellij.openapi.externalSystem.service.internal.AbstractExternalSystemTask.execute(AbstractExternalSystemTask.java:120)
at com.intellij.openapi.externalSystem.util.ExternalSystemUtil$3.execute(ExternalSystemUtil.java:388)
at com.intellij.openapi.externalSystem.util.ExternalSystemUtil$4$2.run(ExternalSystemUtil.java:435)
at com.intellij.openapi.progress.impl.ProgressManagerImpl$TaskRunnable.run(ProgressManagerImpl.java:465)
at com.intellij.openapi.progress.impl.ProgressManagerImpl$2.run(ProgressManagerImpl.java:175)
at com.intellij.openapi.progress.ProgressManager.executeProcessUnderProgress(ProgressManager.java:207)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:209)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.runProcess(ProgressManagerImpl.java:168)
at com.intellij.openapi.progress.impl.ProgressManagerImpl$8.run(ProgressManagerImpl.java:375)
at com.intellij.openapi.application.impl.ApplicationImpl$8.run(ApplicationImpl.java:434)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)
at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:151)
Caused by: org.gradle.internal.UncheckedException: java.io.InvalidClassException: failed to read class descriptor
at org.gradle.internal.UncheckedException.throwAsUncheckedException(UncheckedException.java:39)
at org.gradle.tooling.internal.provider.PayloadSerializer.doDeserialize(PayloadSerializer.java:196)
at org.gradle.tooling.internal.provider.PayloadSerializer.deserialize(PayloadSerializer.java:138)
at org.gradle.tooling.internal.provider.ClientProvidedBuildAction.run(ClientProvidedBuildAction.java:42)
at org.gradle.tooling.internal.provider.ClientProvidedBuildAction.run(ClientProvidedBuildAction.java:32)
at org.gradle.tooling.internal.provider.ConfiguringBuildAction.run(ConfiguringBuildAction.java:108)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:35)
at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:45)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:42)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:24)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.StartStopIfBuildAndStop.execute(StartStopIfBuildAndStop.java:33)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.ReturnResult.execute(ReturnResult.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:71)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:69)
at org.gradle.util.Swapper.swap(Swapper.java:38)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:69)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:60)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:59)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:45)
at org.gradle.launcher.daemon.server.DaemonStateCoordinator.runCommand(DaemonStateCoordinator.java:186)
at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy.doBuild(StartBuildOrRespondWithBusy.java:49)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:34)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.HandleStop.execute(HandleStop.java:36)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.CatchAndForwardDaemonFailure.execute(CatchAndForwardDaemonFailure.java:32)
at org.gradle.launcher.daemon.server.exec.DaemonCommandExecution.proceed(DaemonCommandExecution.java:125)
at org.gradle.launcher.daemon.server.exec.DefaultDaemonCommandExecuter.executeCommand(DefaultDaemonCommandExecuter.java:48)
at org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler$ConnectionWorker.handleCommand(DefaultIncomingConnectionHandler.java:155)
at org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler$ConnectionWorker.receiveAndHandleCommand(DefaultIncomingConnectionHandler.java:128)
at org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler$ConnectionWorker.run(DefaultIncomingConnectionHandler.java:116)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.io.InvalidClassException: failed to read class descriptor
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1580)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1494)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1748)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1327)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
at org.gradle.tooling.internal.provider.PayloadSerializer.doDeserialize(PayloadSerializer.java:194)
... 44 more
Caused by: java.lang.ClassNotFoundException: org.gradle.tooling.internal.consumer.connection.BuildActionAdapter
at org.gradle.internal.classloader.TransformingClassLoader.findClass(TransformingClassLoader.java:41)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:249)
at org.gradle.tooling.internal.provider.PayloadSerializer$2.readClass(PayloadSerializer.java:175)
at org.gradle.tooling.internal.provider.PayloadSerializer$2.readClassDescriptor(PayloadSerializer.java:159)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1578)
... 49 more


On Sat, Aug 10, 2013 at 11:35 AM, kelemen <[hidden email]> wrote:
The new API throws an exception for me. Here is the stacktrace:
https://gist.github.com/kelemen/6201595

And here is the code using the new API:
https://github.com/kelemen/netbeans-gradle-project/blob/d3a82f4f761fc6bf8ebcf75b00ae8da81f89ce58/src/main/java/org/netbeans/gradle/project/model/NbGradle18ModelLoader.java



--
View this message in context: http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711666.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

kelemen
In reply to this post by Adam Murdoch
You can debug my plugin easily:

2. Install NetBeans (I'm using 7.3.1 but should work with 7.2 as well).
3. Build the project.
4. Debug (This will start a new instance of NB).
5. Open any project.

Note 1: It is important to always build the project before run because it seems that NB don't automatically build NB Maven based modules (unlike simple Maven projects).

Note 2: If you want to step into the sources of the Tooling API, you have to right click on the "Dependencies" node and "Download Sources".

Also, you need to configure, the Gradle version used to load the project. You can do this in Tools/Options/Miscellaneous/Gradle for every project but by default the version defined for the wrapper is used, so you can rely on that. Anyway, every method the Tooling API allows is possible to use as a Gradle location. See the wiki: https://github.com/kelemen/netbeans-gradle-project/wiki/Project-Properties ("Gradle home")

These are the new lines printed by the most recent Tooling API:

Tooling API ClassLoader: ModuleCL@91ed751[org.netbeans.gradle.project] (class org.netbeans.StandardModule$OneModuleClassLoader)
    * Classpath: [file:/C:/Program%20Files/NetBeans%207.3/platform/lib/boot.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-modules.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util-lookup.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_zh_CN.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/dt.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/tools.jar]
    * Codesource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/
    * Resource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/org/gradle/tooling/internal/consumer/connection/ActionAwareConsumerConnection$DefaultBuildActionSerializationDetails.class




2013/8/12 Adam Murdoch [via Gradle] <[hidden email]>

I've added some diagnostics to the latest nightly build. Can you give this a try and send me the output. It's logged to System.out.

Also is there some way I can run your code to debug what's going on?

On 11/08/2013, at 4:35 AM, kelemen <[hidden email]> wrote:

--
View this message in context: http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711666.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

alex.ruiz.05
Thanks, Adam. In addition to Attila's example, I'll extract my code into a unit test to make it easier to run.


On Sun, Aug 11, 2013 at 4:37 PM, kelemen <[hidden email]> wrote:
You can debug my plugin easily:

2. Install NetBeans (I'm using 7.3.1 but should work with 7.2 as well).
3. Build the project.
4. Debug (This will start a new instance of NB).
5. Open any project.

Note 1: It is important to always build the project before run because it seems that NB don't automatically build NB Maven based modules (unlike simple Maven projects).

Note 2: If you want to step into the sources of the Tooling API, you have to right click on the "Dependencies" node and "Download Sources".

Also, you need to configure, the Gradle version used to load the project. You can do this in Tools/Options/Miscellaneous/Gradle for every project but by default the version defined for the wrapper is used, so you can rely on that. Anyway, every method the Tooling API allows is possible to use as a Gradle location. See the wiki: https://github.com/kelemen/netbeans-gradle-project/wiki/Project-Properties ("Gradle home")

These are the new lines printed by the most recent Tooling API:

Tooling API ClassLoader: ModuleCL@91ed751[org.netbeans.gradle.project] (class org.netbeans.StandardModule$OneModuleClassLoader)
    * Classpath: [file:/C:/Program%20Files/NetBeans%207.3/platform/lib/boot.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-modules.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util-lookup.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_zh_CN.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/dt.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/tools.jar]
    * Codesource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/
    * Resource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/org/gradle/tooling/internal/consumer/connection/ActionAwareConsumerConnection$DefaultBuildActionSerializationDetails.class




2013/8/12 Adam Murdoch [via Gradle] <[hidden email]>

I've added some diagnostics to the latest nightly build. Can you give this a try and send me the output. It's logged to System.out.

Also is there some way I can run your code to debug what's going on?

On 11/08/2013, at 4:35 AM, kelemen <[hidden email]> wrote:

--
View this message in context: http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711666.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML

Sent from the gradle-dev mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

alex.ruiz.05
Hi Adam,

Thanks to the diagnostics you added, it seems that the problem is in IntelliJ. I'm attaching the output of both Studio (IDEA) and a simple Java app. The classpath from Studio is empty, while the one from the simple Java app is correct. I'm going to test a little bit more on Studio, and if this is an issue with IDEA, I'll let the IDEA folks know about this issue.

Thanks,
-Alex



On Sun, Aug 11, 2013 at 9:54 PM, Alex Ruiz <[hidden email]> wrote:
Thanks, Adam. In addition to Attila's example, I'll extract my code into a unit test to make it easier to run.


On Sun, Aug 11, 2013 at 4:37 PM, kelemen <[hidden email]> wrote:
You can debug my plugin easily:

2. Install NetBeans (I'm using 7.3.1 but should work with 7.2 as well).
3. Build the project.
4. Debug (This will start a new instance of NB).
5. Open any project.

Note 1: It is important to always build the project before run because it seems that NB don't automatically build NB Maven based modules (unlike simple Maven projects).

Note 2: If you want to step into the sources of the Tooling API, you have to right click on the "Dependencies" node and "Download Sources".

Also, you need to configure, the Gradle version used to load the project. You can do this in Tools/Options/Miscellaneous/Gradle for every project but by default the version defined for the wrapper is used, so you can rely on that. Anyway, every method the Tooling API allows is possible to use as a Gradle location. See the wiki: https://github.com/kelemen/netbeans-gradle-project/wiki/Project-Properties ("Gradle home")

These are the new lines printed by the most recent Tooling API:

Tooling API ClassLoader: ModuleCL@91ed751[org.netbeans.gradle.project] (class org.netbeans.StandardModule$OneModuleClassLoader)
    * Classpath: [file:/C:/Program%20Files/NetBeans%207.3/platform/lib/boot.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-modules.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util-lookup.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_zh_CN.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/dt.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/tools.jar]
    * Codesource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/
    * Resource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/org/gradle/tooling/internal/consumer/connection/ActionAwareConsumerConnection$DefaultBuildActionSerializationDetails.class




2013/8/12 Adam Murdoch [via Gradle] <[hidden email]>

I've added some diagnostics to the latest nightly build. Can you give this a try and send me the output. It's logged to System.out.

Also is there some way I can run your code to debug what's going on?

On 11/08/2013, at 4:35 AM, kelemen <[hidden email]> wrote:

--
View this message in context: http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711666.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML

Sent from the gradle-dev mailing list archive at Nabble.com.




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

gradle-output-app.txt (7K) Download Attachment
gradle-output-studio.txt (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

alex.ruiz.05
Hi Adam,

I did some testing and, in fact, the problem is in IntelliJ. Long story short: they recently (as in last Friday) removed usage of RMI to import a Gradle project into IDEA (or Studio.) The classpath is not correctly set with RMI off. With RMI on the classpath is properly set, and the new API works. I haven't tested our whole use case, but at least with RMI on, we don't get the 'class not found' exception.

I'll follow up with the IntelliJ folks.

Thanks!
-Alex


On Mon, Aug 12, 2013 at 12:20 AM, Alex Ruiz <[hidden email]> wrote:
Hi Adam,

Thanks to the diagnostics you added, it seems that the problem is in IntelliJ. I'm attaching the output of both Studio (IDEA) and a simple Java app. The classpath from Studio is empty, while the one from the simple Java app is correct. I'm going to test a little bit more on Studio, and if this is an issue with IDEA, I'll let the IDEA folks know about this issue.

Thanks,
-Alex



On Sun, Aug 11, 2013 at 9:54 PM, Alex Ruiz <[hidden email]> wrote:
Thanks, Adam. In addition to Attila's example, I'll extract my code into a unit test to make it easier to run.


On Sun, Aug 11, 2013 at 4:37 PM, kelemen <[hidden email]> wrote:
You can debug my plugin easily:

2. Install NetBeans (I'm using 7.3.1 but should work with 7.2 as well).
3. Build the project.
4. Debug (This will start a new instance of NB).
5. Open any project.

Note 1: It is important to always build the project before run because it seems that NB don't automatically build NB Maven based modules (unlike simple Maven projects).

Note 2: If you want to step into the sources of the Tooling API, you have to right click on the "Dependencies" node and "Download Sources".

Also, you need to configure, the Gradle version used to load the project. You can do this in Tools/Options/Miscellaneous/Gradle for every project but by default the version defined for the wrapper is used, so you can rely on that. Anyway, every method the Tooling API allows is possible to use as a Gradle location. See the wiki: https://github.com/kelemen/netbeans-gradle-project/wiki/Project-Properties ("Gradle home")

These are the new lines printed by the most recent Tooling API:

Tooling API ClassLoader: ModuleCL@91ed751[org.netbeans.gradle.project] (class org.netbeans.StandardModule$OneModuleClassLoader)
    * Classpath: [file:/C:/Program%20Files/NetBeans%207.3/platform/lib/boot.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-modules.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util-lookup.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_zh_CN.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/dt.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/tools.jar]
    * Codesource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/
    * Resource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/org/gradle/tooling/internal/consumer/connection/ActionAwareConsumerConnection$DefaultBuildActionSerializationDetails.class




2013/8/12 Adam Murdoch [via Gradle] <[hidden email]>

I've added some diagnostics to the latest nightly build. Can you give this a try and send me the output. It's logged to System.out.

Also is there some way I can run your code to debug what's going on?

On 11/08/2013, at 4:35 AM, kelemen <[hidden email]> wrote:

--
View this message in context: http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711666.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML

Sent from the gradle-dev mailing list archive at Nabble.com.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

kelemen
I would rather not simply consider this as an Idea bug because the same error is thrown in NetBeans and it would be good to know what would happen in Eclipse too. Also, I would like to test this when I wrap code from another plugin of NetBeans (using another ClassLoader).


2013/8/12 alex.ruiz.05 [via Gradle] <[hidden email]>
Hi Adam,

I did some testing and, in fact, the problem is in IntelliJ. Long story short: they recently (as in last Friday) removed usage of RMI to import a Gradle project into IDEA (or Studio.) The classpath is not correctly set with RMI off. With RMI on the classpath is properly set, and the new API works. I haven't tested our whole use case, but at least with RMI on, we don't get the 'class not found' exception.

I'll follow up with the IntelliJ folks.

Thanks!
-Alex


On Mon, Aug 12, 2013 at 12:20 AM, Alex Ruiz <[hidden email]> wrote:
Hi Adam,

Thanks to the diagnostics you added, it seems that the problem is in IntelliJ. I'm attaching the output of both Studio (IDEA) and a simple Java app. The classpath from Studio is empty, while the one from the simple Java app is correct. I'm going to test a little bit more on Studio, and if this is an issue with IDEA, I'll let the IDEA folks know about this issue.

Thanks,
-Alex



On Sun, Aug 11, 2013 at 9:54 PM, Alex Ruiz <[hidden email]> wrote:
Thanks, Adam. In addition to Attila's example, I'll extract my code into a unit test to make it easier to run.


On Sun, Aug 11, 2013 at 4:37 PM, kelemen <[hidden email]> wrote:
You can debug my plugin easily:

2. Install NetBeans (I'm using 7.3.1 but should work with 7.2 as well).
3. Build the project.
4. Debug (This will start a new instance of NB).
5. Open any project.

Note 1: It is important to always build the project before run because it seems that NB don't automatically build NB Maven based modules (unlike simple Maven projects).

Note 2: If you want to step into the sources of the Tooling API, you have to right click on the "Dependencies" node and "Download Sources".

Also, you need to configure, the Gradle version used to load the project. You can do this in Tools/Options/Miscellaneous/Gradle for every project but by default the version defined for the wrapper is used, so you can rely on that. Anyway, every method the Tooling API allows is possible to use as a Gradle location. See the wiki: https://github.com/kelemen/netbeans-gradle-project/wiki/Project-Properties ("Gradle home")

These are the new lines printed by the most recent Tooling API:

Tooling API ClassLoader: ModuleCL@91ed751[org.netbeans.gradle.project] (class org.netbeans.StandardModule$OneModuleClassLoader)
    * Classpath: [file:/C:/Program%20Files/NetBeans%207.3/platform/lib/boot.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-modules.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util-lookup.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_zh_CN.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/dt.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/tools.jar]
    * Codesource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/
    * Resource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/org/gradle/tooling/internal/consumer/connection/ActionAwareConsumerConnection$DefaultBuildActionSerializationDetails.class




2013/8/12 Adam Murdoch [via Gradle] <[hidden email]>

I've added some diagnostics to the latest nightly build. Can you give this a try and send me the output. It's logged to System.out.

Also is there some way I can run your code to debug what's going on?

On 11/08/2013, at 4:35 AM, kelemen <[hidden email]> wrote:

--
View this message in context: http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711666.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML

Sent from the gradle-dev mailing list archive at Nabble.com.






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

alex.ruiz.05
Even if this happens in Eclipse, we are not giving Adam enough information to troubleshoot the problem (assuming the problem is in Gradle, which I'm not sure.)

I'm looking into how IDEA does things, to verify where the problem is and if it possible to do something in IDEA to solve the classpath issue. I will check with the IJ folks (once I understand how IDEA is doing the RMI-less import,) they definitely have a better understanding of classloading in IDEA, and they may find a solution (which may help solve the issue in other IDEs.) 


On Mon, Aug 12, 2013 at 12:42 AM, kelemen <[hidden email]> wrote:
I would rather not simply consider this as an Idea bug because the same error is thrown in NetBeans and it would be good to know what would happen in Eclipse too. Also, I would like to test this when I wrap code from another plugin of NetBeans (using another ClassLoader).


2013/8/12 alex.ruiz.05 [via Gradle] <[hidden email]>
Hi Adam,

I did some testing and, in fact, the problem is in IntelliJ. Long story short: they recently (as in last Friday) removed usage of RMI to import a Gradle project into IDEA (or Studio.) The classpath is not correctly set with RMI off. With RMI on the classpath is properly set, and the new API works. I haven't tested our whole use case, but at least with RMI on, we don't get the 'class not found' exception.

I'll follow up with the IntelliJ folks.

Thanks!
-Alex


On Mon, Aug 12, 2013 at 12:20 AM, Alex Ruiz <[hidden email]> wrote:
Hi Adam,

Thanks to the diagnostics you added, it seems that the problem is in IntelliJ. I'm attaching the output of both Studio (IDEA) and a simple Java app. The classpath from Studio is empty, while the one from the simple Java app is correct. I'm going to test a little bit more on Studio, and if this is an issue with IDEA, I'll let the IDEA folks know about this issue.

Thanks,
-Alex



On Sun, Aug 11, 2013 at 9:54 PM, Alex Ruiz <[hidden email]> wrote:
Thanks, Adam. In addition to Attila's example, I'll extract my code into a unit test to make it easier to run.


On Sun, Aug 11, 2013 at 4:37 PM, kelemen <[hidden email]> wrote:
You can debug my plugin easily:

2. Install NetBeans (I'm using 7.3.1 but should work with 7.2 as well).
3. Build the project.
4. Debug (This will start a new instance of NB).
5. Open any project.

Note 1: It is important to always build the project before run because it seems that NB don't automatically build NB Maven based modules (unlike simple Maven projects).

Note 2: If you want to step into the sources of the Tooling API, you have to right click on the "Dependencies" node and "Download Sources".

Also, you need to configure, the Gradle version used to load the project. You can do this in Tools/Options/Miscellaneous/Gradle for every project but by default the version defined for the wrapper is used, so you can rely on that. Anyway, every method the Tooling API allows is possible to use as a Gradle location. See the wiki: https://github.com/kelemen/netbeans-gradle-project/wiki/Project-Properties ("Gradle home")

These are the new lines printed by the most recent Tooling API:

Tooling API ClassLoader: ModuleCL@91ed751[org.netbeans.gradle.project] (class org.netbeans.StandardModule$OneModuleClassLoader)
    * Classpath: [file:/C:/Program%20Files/NetBeans%207.3/platform/lib/boot.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-modules.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util-lookup.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_zh_CN.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/dt.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/tools.jar]
    * Codesource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/
    * Resource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/org/gradle/tooling/internal/consumer/connection/ActionAwareConsumerConnection$DefaultBuildActionSerializationDetails.class




2013/8/12 Adam Murdoch [via Gradle] <[hidden email]>

I've added some diagnostics to the latest nightly build. Can you give this a try and send me the output. It's logged to System.out.

Also is there some way I can run your code to debug what's going on?

On 11/08/2013, at 4:35 AM, kelemen <[hidden email]> wrote:

--
View this message in context: http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711666.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML

Sent from the gradle-dev mailing list archive at Nabble.com.






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

kelemen
I have debugged into the Tooling API and see what it does to determine the required jar files. Actually, I believe that the problem is not the fault of the IDE. Gradle makes two wrong assumptions:

1. URLClassLoader instances are used in the class loader hierarchy. Actually, NetBeans has a different class loader which prevents accessing classes not for the NB module.
2. The ClassLoader of the class implementing BuildAction is enough. This is not true because I have to wrap other plugins' actions as well (such as NBAndroid) and they use an unrelated ClassLoader.

This issue is by far not trivial to solve and I don't know if Gradle can solve this on its own without the client code (e.g.: NB Gradle plugin) telling it where additional jars are located.


2013/8/12 alex.ruiz.05 [via Gradle] <[hidden email]>
Even if this happens in Eclipse, we are not giving Adam enough information to troubleshoot the problem (assuming the problem is in Gradle, which I'm not sure.)

I'm looking into how IDEA does things, to verify where the problem is and if it possible to do something in IDEA to solve the classpath issue. I will check with the IJ folks (once I understand how IDEA is doing the RMI-less import,) they definitely have a better understanding of classloading in IDEA, and they may find a solution (which may help solve the issue in other IDEs.) 


On Mon, Aug 12, 2013 at 12:42 AM, kelemen <[hidden email]> wrote:
I would rather not simply consider this as an Idea bug because the same error is thrown in NetBeans and it would be good to know what would happen in Eclipse too. Also, I would like to test this when I wrap code from another plugin of NetBeans (using another ClassLoader).


2013/8/12 alex.ruiz.05 [via Gradle] <[hidden email]>

Hi Adam,

I did some testing and, in fact, the problem is in IntelliJ. Long story short: they recently (as in last Friday) removed usage of RMI to import a Gradle project into IDEA (or Studio.) The classpath is not correctly set with RMI off. With RMI on the classpath is properly set, and the new API works. I haven't tested our whole use case, but at least with RMI on, we don't get the 'class not found' exception.

I'll follow up with the IntelliJ folks.

Thanks!
-Alex


On Mon, Aug 12, 2013 at 12:20 AM, Alex Ruiz <[hidden email]> wrote:
Hi Adam,

Thanks to the diagnostics you added, it seems that the problem is in IntelliJ. I'm attaching the output of both Studio (IDEA) and a simple Java app. The classpath from Studio is empty, while the one from the simple Java app is correct. I'm going to test a little bit more on Studio, and if this is an issue with IDEA, I'll let the IDEA folks know about this issue.

Thanks,
-Alex



On Sun, Aug 11, 2013 at 9:54 PM, Alex Ruiz <[hidden email]> wrote:
Thanks, Adam. In addition to Attila's example, I'll extract my code into a unit test to make it easier to run.


On Sun, Aug 11, 2013 at 4:37 PM, kelemen <[hidden email]> wrote:
You can debug my plugin easily:

2. Install NetBeans (I'm using 7.3.1 but should work with 7.2 as well).
3. Build the project.
4. Debug (This will start a new instance of NB).
5. Open any project.

Note 1: It is important to always build the project before run because it seems that NB don't automatically build NB Maven based modules (unlike simple Maven projects).

Note 2: If you want to step into the sources of the Tooling API, you have to right click on the "Dependencies" node and "Download Sources".

Also, you need to configure, the Gradle version used to load the project. You can do this in Tools/Options/Miscellaneous/Gradle for every project but by default the version defined for the wrapper is used, so you can rely on that. Anyway, every method the Tooling API allows is possible to use as a Gradle location. See the wiki: https://github.com/kelemen/netbeans-gradle-project/wiki/Project-Properties ("Gradle home")

These are the new lines printed by the most recent Tooling API:

Tooling API ClassLoader: ModuleCL@91ed751[org.netbeans.gradle.project] (class org.netbeans.StandardModule$OneModuleClassLoader)
    * Classpath: [file:/C:/Program%20Files/NetBeans%207.3/platform/lib/boot.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-modules.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util-lookup.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_zh_CN.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/dt.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/tools.jar]
    * Codesource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/
    * Resource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/org/gradle/tooling/internal/consumer/connection/ActionAwareConsumerConnection$DefaultBuildActionSerializationDetails.class




2013/8/12 Adam Murdoch [via Gradle] <[hidden email]>

I've added some diagnostics to the latest nightly build. Can you give this a try and send me the output. It's logged to System.out.

Also is there some way I can run your code to debug what's going on?

On 11/08/2013, at 4:35 AM, kelemen <[hidden email]> wrote:

--
View this message in context: http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711666.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML

Sent from the gradle-dev mailing list archive at Nabble.com.






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML





To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

alex.ruiz.05
I quite don't see things the same way. The new API provides something really powerful: perform custom logic in Gradle *without* writing plug-ins. The main use case is IDEs and the custom logic resides in the IDE (and can evolve with the IDE without end-users needing to update their build scripts, or plug-in versions, etc.)

It would be ideal to drop in this new API and have everything work magically. But I don't think this is 100% possible. It is a tough problem. Both sides (client code and Gradle) need to know about each other somehow in order to operate (Adam, please correct if I'm wrong.) Either Gradle knows about the IDE or the IDE knows about Gradle. The IDE already knows about Gradle, after all it has a plug-in already using Gradle APIs. My take is that if this API requires changes in clients (IDEs) it is worth doing them for all the benefits the API provides (unless, of course, Adam has a way to go around this.)

In the case of IDEA (and Studio), the IntelliJ folks are already working on a way to let us specify the classpath necessary for this new API to work: http://youtrack.jetbrains.com/issue/IDEA-111910 .




On Mon, Aug 12, 2013 at 6:32 AM, kelemen <[hidden email]> wrote:
I have debugged into the Tooling API and see what it does to determine the required jar files. Actually, I believe that the problem is not the fault of the IDE. Gradle makes two wrong assumptions:

1. URLClassLoader instances are used in the class loader hierarchy. Actually, NetBeans has a different class loader which prevents accessing classes not for the NB module.
2. The ClassLoader of the class implementing BuildAction is enough. This is not true because I have to wrap other plugins' actions as well (such as NBAndroid) and they use an unrelated ClassLoader.

This issue is by far not trivial to solve and I don't know if Gradle can solve this on its own without the client code (e.g.: NB Gradle plugin) telling it where additional jars are located.


2013/8/12 alex.ruiz.05 [via Gradle] <[hidden email]>
Even if this happens in Eclipse, we are not giving Adam enough information to troubleshoot the problem (assuming the problem is in Gradle, which I'm not sure.)

I'm looking into how IDEA does things, to verify where the problem is and if it possible to do something in IDEA to solve the classpath issue. I will check with the IJ folks (once I understand how IDEA is doing the RMI-less import,) they definitely have a better understanding of classloading in IDEA, and they may find a solution (which may help solve the issue in other IDEs.) 


On Mon, Aug 12, 2013 at 12:42 AM, kelemen <[hidden email]> wrote:
I would rather not simply consider this as an Idea bug because the same error is thrown in NetBeans and it would be good to know what would happen in Eclipse too. Also, I would like to test this when I wrap code from another plugin of NetBeans (using another ClassLoader).


2013/8/12 alex.ruiz.05 [via Gradle] <[hidden email]>

Hi Adam,

I did some testing and, in fact, the problem is in IntelliJ. Long story short: they recently (as in last Friday) removed usage of RMI to import a Gradle project into IDEA (or Studio.) The classpath is not correctly set with RMI off. With RMI on the classpath is properly set, and the new API works. I haven't tested our whole use case, but at least with RMI on, we don't get the 'class not found' exception.

I'll follow up with the IntelliJ folks.

Thanks!
-Alex


On Mon, Aug 12, 2013 at 12:20 AM, Alex Ruiz <[hidden email]> wrote:
Hi Adam,

Thanks to the diagnostics you added, it seems that the problem is in IntelliJ. I'm attaching the output of both Studio (IDEA) and a simple Java app. The classpath from Studio is empty, while the one from the simple Java app is correct. I'm going to test a little bit more on Studio, and if this is an issue with IDEA, I'll let the IDEA folks know about this issue.

Thanks,
-Alex



On Sun, Aug 11, 2013 at 9:54 PM, Alex Ruiz <[hidden email]> wrote:
Thanks, Adam. In addition to Attila's example, I'll extract my code into a unit test to make it easier to run.


On Sun, Aug 11, 2013 at 4:37 PM, kelemen <[hidden email]> wrote:
You can debug my plugin easily:

2. Install NetBeans (I'm using 7.3.1 but should work with 7.2 as well).
3. Build the project.
4. Debug (This will start a new instance of NB).
5. Open any project.

Note 1: It is important to always build the project before run because it seems that NB don't automatically build NB Maven based modules (unlike simple Maven projects).

Note 2: If you want to step into the sources of the Tooling API, you have to right click on the "Dependencies" node and "Download Sources".

Also, you need to configure, the Gradle version used to load the project. You can do this in Tools/Options/Miscellaneous/Gradle for every project but by default the version defined for the wrapper is used, so you can rely on that. Anyway, every method the Tooling API allows is possible to use as a Gradle location. See the wiki: https://github.com/kelemen/netbeans-gradle-project/wiki/Project-Properties ("Gradle home")

These are the new lines printed by the most recent Tooling API:

Tooling API ClassLoader: ModuleCL@91ed751[org.netbeans.gradle.project] (class org.netbeans.StandardModule$OneModuleClassLoader)
    * Classpath: [file:/C:/Program%20Files/NetBeans%207.3/platform/lib/boot.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-modules.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util-lookup.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_zh_CN.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/dt.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/tools.jar]
    * Codesource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/
    * Resource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/org/gradle/tooling/internal/consumer/connection/ActionAwareConsumerConnection$DefaultBuildActionSerializationDetails.class




2013/8/12 Adam Murdoch [via Gradle] <[hidden email]>

I've added some diagnostics to the latest nightly build. Can you give this a try and send me the output. It's logged to System.out.

Also is there some way I can run your code to debug what's going on?

On 11/08/2013, at 4:35 AM, kelemen <[hidden email]> wrote:

--
View this message in context: http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711666.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML

Sent from the gradle-dev mailing list archive at Nabble.com.






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML





To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

kelemen
I don't see how your opinion differs from mine. Actually, I agree with what you wrote. I just stated that as I have seen in the sources of Gradle, things will not work out with the current way. That is, I don't see how it could. Changing how the class loading mechanism works in NetBeans is practically impossible. NetBeans is a platform, not just an IDE and even if it was not, possibly many code out there already relies on its class loading mechanism. Breaking them is not an option, the risk of this change seems extremely high to me. Other that this, I'm prepared to change the way my plugin works, if it makes the Tooling API better but to make fundamental changes in the NetBeans platform is unlikely to happen.


2013/8/12 alex.ruiz.05 [via Gradle] <[hidden email]>
I quite don't see things the same way. The new API provides something really powerful: perform custom logic in Gradle *without* writing plug-ins. The main use case is IDEs and the custom logic resides in the IDE (and can evolve with the IDE without end-users needing to update their build scripts, or plug-in versions, etc.)

It would be ideal to drop in this new API and have everything work magically. But I don't think this is 100% possible. It is a tough problem. Both sides (client code and Gradle) need to know about each other somehow in order to operate (Adam, please correct if I'm wrong.) Either Gradle knows about the IDE or the IDE knows about Gradle. The IDE already knows about Gradle, after all it has a plug-in already using Gradle APIs. My take is that if this API requires changes in clients (IDEs) it is worth doing them for all the benefits the API provides (unless, of course, Adam has a way to go around this.)

In the case of IDEA (and Studio), the IntelliJ folks are already working on a way to let us specify the classpath necessary for this new API to work: http://youtrack.jetbrains.com/issue/IDEA-111910 .




On Mon, Aug 12, 2013 at 6:32 AM, kelemen <[hidden email]> wrote:
I have debugged into the Tooling API and see what it does to determine the required jar files. Actually, I believe that the problem is not the fault of the IDE. Gradle makes two wrong assumptions:

1. URLClassLoader instances are used in the class loader hierarchy. Actually, NetBeans has a different class loader which prevents accessing classes not for the NB module.
2. The ClassLoader of the class implementing BuildAction is enough. This is not true because I have to wrap other plugins' actions as well (such as NBAndroid) and they use an unrelated ClassLoader.

This issue is by far not trivial to solve and I don't know if Gradle can solve this on its own without the client code (e.g.: NB Gradle plugin) telling it where additional jars are located.


2013/8/12 alex.ruiz.05 [via Gradle] <[hidden email]>
Even if this happens in Eclipse, we are not giving Adam enough information to troubleshoot the problem (assuming the problem is in Gradle, which I'm not sure.)

I'm looking into how IDEA does things, to verify where the problem is and if it possible to do something in IDEA to solve the classpath issue. I will check with the IJ folks (once I understand how IDEA is doing the RMI-less import,) they definitely have a better understanding of classloading in IDEA, and they may find a solution (which may help solve the issue in other IDEs.) 


On Mon, Aug 12, 2013 at 12:42 AM, kelemen <[hidden email]> wrote:
I would rather not simply consider this as an Idea bug because the same error is thrown in NetBeans and it would be good to know what would happen in Eclipse too. Also, I would like to test this when I wrap code from another plugin of NetBeans (using another ClassLoader).


2013/8/12 alex.ruiz.05 [via Gradle] <[hidden email]>

Hi Adam,

I did some testing and, in fact, the problem is in IntelliJ. Long story short: they recently (as in last Friday) removed usage of RMI to import a Gradle project into IDEA (or Studio.) The classpath is not correctly set with RMI off. With RMI on the classpath is properly set, and the new API works. I haven't tested our whole use case, but at least with RMI on, we don't get the 'class not found' exception.

I'll follow up with the IntelliJ folks.

Thanks!
-Alex


On Mon, Aug 12, 2013 at 12:20 AM, Alex Ruiz <[hidden email]> wrote:
Hi Adam,

Thanks to the diagnostics you added, it seems that the problem is in IntelliJ. I'm attaching the output of both Studio (IDEA) and a simple Java app. The classpath from Studio is empty, while the one from the simple Java app is correct. I'm going to test a little bit more on Studio, and if this is an issue with IDEA, I'll let the IDEA folks know about this issue.

Thanks,
-Alex



On Sun, Aug 11, 2013 at 9:54 PM, Alex Ruiz <[hidden email]> wrote:
Thanks, Adam. In addition to Attila's example, I'll extract my code into a unit test to make it easier to run.


On Sun, Aug 11, 2013 at 4:37 PM, kelemen <[hidden email]> wrote:
You can debug my plugin easily:

2. Install NetBeans (I'm using 7.3.1 but should work with 7.2 as well).
3. Build the project.
4. Debug (This will start a new instance of NB).
5. Open any project.

Note 1: It is important to always build the project before run because it seems that NB don't automatically build NB Maven based modules (unlike simple Maven projects).

Note 2: If you want to step into the sources of the Tooling API, you have to right click on the "Dependencies" node and "Download Sources".

Also, you need to configure, the Gradle version used to load the project. You can do this in Tools/Options/Miscellaneous/Gradle for every project but by default the version defined for the wrapper is used, so you can rely on that. Anyway, every method the Tooling API allows is possible to use as a Gradle location. See the wiki: https://github.com/kelemen/netbeans-gradle-project/wiki/Project-Properties ("Gradle home")

These are the new lines printed by the most recent Tooling API:

Tooling API ClassLoader: ModuleCL@91ed751[org.netbeans.gradle.project] (class org.netbeans.StandardModule$OneModuleClassLoader)
    * Classpath: [file:/C:/Program%20Files/NetBeans%207.3/platform/lib/boot.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-modules.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util-lookup.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_zh_CN.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/dt.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/tools.jar]
    * Codesource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/
    * Resource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/org/gradle/tooling/internal/consumer/connection/ActionAwareConsumerConnection$DefaultBuildActionSerializationDetails.class




2013/8/12 Adam Murdoch [via Gradle] <[hidden email]>

I've added some diagnostics to the latest nightly build. Can you give this a try and send me the output. It's logged to System.out.

Also is there some way I can run your code to debug what's going on?

On 11/08/2013, at 4:35 AM, kelemen <[hidden email]> wrote:

--
View this message in context: http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711666.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML

Sent from the gradle-dev mailing list archive at Nabble.com.






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML





To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML





To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API

kelemen
In reply to this post by alex.ruiz.05
It just occurred to me that there is another problem with automatic class path detection:

1. My plugin currently uses Java6 and I plan to switch to Java7 this year (since NB switches as well).
2. If the class path is detected automatically then it will put jars not compatible with Java6 (or worse with Java7) on the classpath (if not mine, then NB jars of which I cannot do anything about).
3. This means, that the daemon must use Java6 or Java7 as well.
4. Since Gradle allows users to use Java5 (as far as I know), it would be rude of me to require the user to use Java7.

So, I believe I'm forced to create another project which needs only Java5 and depend on that project and only put this one jar (and its dependencies) to the classpath (for the daemon be able to use my BuildAction implementation).

By the way, this is something to consider for AndroidStudio as well (as far as I know it needs Java6 as well).



2013/8/12 Kelemen Attila <[hidden email]>
I don't see how your opinion differs from mine. Actually, I agree with what you wrote. I just stated that as I have seen in the sources of Gradle, things will not work out with the current way. That is, I don't see how it could. Changing how the class loading mechanism works in NetBeans is practically impossible. NetBeans is a platform, not just an IDE and even if it was not, possibly many code out there already relies on its class loading mechanism. Breaking them is not an option, the risk of this change seems extremely high to me. Other that this, I'm prepared to change the way my plugin works, if it makes the Tooling API better but to make fundamental changes in the NetBeans platform is unlikely to happen.


2013/8/12 alex.ruiz.05 [via Gradle] <[hidden email]>

I quite don't see things the same way. The new API provides something really powerful: perform custom logic in Gradle *without* writing plug-ins. The main use case is IDEs and the custom logic resides in the IDE (and can evolve with the IDE without end-users needing to update their build scripts, or plug-in versions, etc.)

It would be ideal to drop in this new API and have everything work magically. But I don't think this is 100% possible. It is a tough problem. Both sides (client code and Gradle) need to know about each other somehow in order to operate (Adam, please correct if I'm wrong.) Either Gradle knows about the IDE or the IDE knows about Gradle. The IDE already knows about Gradle, after all it has a plug-in already using Gradle APIs. My take is that if this API requires changes in clients (IDEs) it is worth doing them for all the benefits the API provides (unless, of course, Adam has a way to go around this.)

In the case of IDEA (and Studio), the IntelliJ folks are already working on a way to let us specify the classpath necessary for this new API to work: http://youtrack.jetbrains.com/issue/IDEA-111910 .




On Mon, Aug 12, 2013 at 6:32 AM, kelemen <[hidden email]> wrote:
I have debugged into the Tooling API and see what it does to determine the required jar files. Actually, I believe that the problem is not the fault of the IDE. Gradle makes two wrong assumptions:

1. URLClassLoader instances are used in the class loader hierarchy. Actually, NetBeans has a different class loader which prevents accessing classes not for the NB module.
2. The ClassLoader of the class implementing BuildAction is enough. This is not true because I have to wrap other plugins' actions as well (such as NBAndroid) and they use an unrelated ClassLoader.

This issue is by far not trivial to solve and I don't know if Gradle can solve this on its own without the client code (e.g.: NB Gradle plugin) telling it where additional jars are located.


2013/8/12 alex.ruiz.05 [via Gradle] <[hidden email]>
Even if this happens in Eclipse, we are not giving Adam enough information to troubleshoot the problem (assuming the problem is in Gradle, which I'm not sure.)

I'm looking into how IDEA does things, to verify where the problem is and if it possible to do something in IDEA to solve the classpath issue. I will check with the IJ folks (once I understand how IDEA is doing the RMI-less import,) they definitely have a better understanding of classloading in IDEA, and they may find a solution (which may help solve the issue in other IDEs.) 


On Mon, Aug 12, 2013 at 12:42 AM, kelemen <[hidden email]> wrote:
I would rather not simply consider this as an Idea bug because the same error is thrown in NetBeans and it would be good to know what would happen in Eclipse too. Also, I would like to test this when I wrap code from another plugin of NetBeans (using another ClassLoader).


2013/8/12 alex.ruiz.05 [via Gradle] <[hidden email]>

Hi Adam,

I did some testing and, in fact, the problem is in IntelliJ. Long story short: they recently (as in last Friday) removed usage of RMI to import a Gradle project into IDEA (or Studio.) The classpath is not correctly set with RMI off. With RMI on the classpath is properly set, and the new API works. I haven't tested our whole use case, but at least with RMI on, we don't get the 'class not found' exception.

I'll follow up with the IntelliJ folks.

Thanks!
-Alex


On Mon, Aug 12, 2013 at 12:20 AM, Alex Ruiz <[hidden email]> wrote:
Hi Adam,

Thanks to the diagnostics you added, it seems that the problem is in IntelliJ. I'm attaching the output of both Studio (IDEA) and a simple Java app. The classpath from Studio is empty, while the one from the simple Java app is correct. I'm going to test a little bit more on Studio, and if this is an issue with IDEA, I'll let the IDEA folks know about this issue.

Thanks,
-Alex



On Sun, Aug 11, 2013 at 9:54 PM, Alex Ruiz <[hidden email]> wrote:
Thanks, Adam. In addition to Attila's example, I'll extract my code into a unit test to make it easier to run.


On Sun, Aug 11, 2013 at 4:37 PM, kelemen <[hidden email]> wrote:
You can debug my plugin easily:

2. Install NetBeans (I'm using 7.3.1 but should work with 7.2 as well).
3. Build the project.
4. Debug (This will start a new instance of NB).
5. Open any project.

Note 1: It is important to always build the project before run because it seems that NB don't automatically build NB Maven based modules (unlike simple Maven projects).

Note 2: If you want to step into the sources of the Tooling API, you have to right click on the "Dependencies" node and "Download Sources".

Also, you need to configure, the Gradle version used to load the project. You can do this in Tools/Options/Miscellaneous/Gradle for every project but by default the version defined for the wrapper is used, so you can rely on that. Anyway, every method the Tooling API allows is possible to use as a Gradle location. See the wiki: https://github.com/kelemen/netbeans-gradle-project/wiki/Project-Properties ("Gradle home")

These are the new lines printed by the most recent Tooling API:

Tooling API ClassLoader: ModuleCL@91ed751[org.netbeans.gradle.project] (class org.netbeans.StandardModule$OneModuleClassLoader)
    * Classpath: [file:/C:/Program%20Files/NetBeans%207.3/platform/lib/boot.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-modules.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util-lookup.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_zh_CN.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ja.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_pt_BR.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ru.jar, file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_zh_CN.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/dt.jar, file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/tools.jar]
    * Codesource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/
    * Resource: jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/org/gradle/tooling/internal/consumer/connection/ActionAwareConsumerConnection$DefaultBuildActionSerializationDetails.class




2013/8/12 Adam Murdoch [via Gradle] <[hidden email]>

I've added some diagnostics to the latest nightly build. Can you give this a try and send me the output. It's logged to System.out.

Also is there some way I can run your code to debug what's going on?

On 11/08/2013, at 4:35 AM, kelemen <[hidden email]> wrote:

--
View this message in context: http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711666.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML

Sent from the gradle-dev mailing list archive at Nabble.com.






To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML





To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML





To unsubscribe from Proposal for retrieving multiple types of models from a project in a single pass, using the Tooling API, click here.
NAML


123456
Loading...