tooling-api, the not idea/eclipse use case !

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

tooling-api, the not idea/eclipse use case !

Magnus Rundberget-3
Hi !

I'm currently working on creating a gradle/groovy plugin for the Light Table editor (more texteditor than IDE). I haven't spent that much time getting to now the API and what you can do. But I do have some (perhaps premature) observations and questions though :-)
Before I start I'd like to state it's great to have the api in the first place and I appreciate the commitment to backwards compatibility !

My use cases/wishes:
I don't wish to replicate IntelliJ or Eclipse (or Netbeans) in any way shape or form. But I do wish to be able to edit my projects in a lightweight super hackable editor and still be able to do things like:
- Anything that has to do with building is handled by the gradle
- Build my project (or invoke selectable build tasks)
- Continuously run tests (if I choose to)
- Test a single unit and preferably see test results inline in my editor
- Visualize all the dependencies of my project (and their interdependencies)
- Get the full runtime classpath (so that I can "repl" against my project where thats feasible/makes sense)
- And probably a whole host of other things when things mature

My Gradle projects contains a really rich model, but my initial impression is that the tooling-api really only exposes a teeny-weeny fraction and it's very much geared towards the two big IDE's. I can appreciate why that might be the case, but I'd love to hear that the plan is to provide mechanisms to make it easy to suck out as much as possible of the rich model information of the gradle project model as possible :-)

It really feels wrong to retrieve an IdeaModel to get hold of my project dependencies. A generic GradleModel or JVMModel or whatever makes more sense to me for an API for common consumption (let IDEA/eclipse have their own plugin/api modules depending on a common tooling api module) !

I might be a little uninformed. It does seem to be an option to create your own custom model, but I'm guessing that this must be a separate plugin that I then must "force" my projects to apply in order to be able to actually use it ?


I can summarize my wishes in two categories:
1. Invoking the build (and get much richer feedback than today: Test results, assertion errors, compilation errors etc etc)
2. Retrieve data from the richness of my defined gradle projects. Focus being on data ! For my usage strong typing, advanced hierarchies, interface/impl separations etc are not what I'm after. I wish to work on datastructures (maps, lists etc works a charm). However since I use groovy, class structures are usually not that much of a hassle. But if I for a custom model end up having to implement tons of dataholding only classes, then I wouldn't be a happy camper.

I guess I'm starting to get damaged by working with Clojure and I fully comprehend that other (and much larger users) have other wishes/drivers


Reading through this:

Am I for off if I'm guessing that any hopes I would have of a rich generic GradleModel/JVMModel in the tooling api is probably not on the roadmap and my best bet would be to implement my own model ?
(I also fully appreciate that there are many dimensions to this when you factor in shipped and custom plugins, api changes, versioning etc etc.)


cheers for the great work with Gradle and  +1 to any endeavours for making the tooling api even cooler !

-magnus




Reply | Threaded
Open this post in threaded view
|

Re: tooling-api, the not idea/eclipse use case !

Radim Kubacki
Hello Magnus,

adding Gradle support to editors/IDEs like Light Table sounds great to me! And you have done a great job looking at what there is currently available and summarizing what you need. Let me comment that:


On Fri, May 16, 2014 at 11:20 PM, Magnus Rundberget <[hidden email]> wrote:
Hi !

I'm currently working on creating a gradle/groovy plugin for the Light Table editor (more texteditor than IDE). I haven't spent that much time getting to now the API and what you can do. But I do have some (perhaps premature) observations and questions though :-)
Before I start I'd like to state it's great to have the api in the first place and I appreciate the commitment to backwards compatibility !

My use cases/wishes:
I don't wish to replicate IntelliJ or Eclipse (or Netbeans) in any way shape or form. But I do wish to be able to edit my projects in a lightweight super hackable editor and still be able to do things like:
- Anything that has to do with building is handled by the gradle
Sure. That makes perfect sense for any lightweight editor/IDE.
 
- Build my project (or invoke selectable build tasks)
That is possible right now and we did some improvements recently to give Tooling API clients better information about tasks and will continue the work in this direction.
 
- Continuously run tests (if I choose to)
- Test a single unit and preferably see test results inline in my editor
Cool. These two are related and it can be a bit tricky depending on what tests you actually want to run and how often. It is possible now but it is not so nice as I would like it to be and it is on our list of things to do.
 
- Visualize all the dependencies of my project (and their interdependencies)
You can use http://www.gradle.org/docs/current/javadoc/org/gradle/tooling/model/gradle/GradleBuild.html as a starting point and let's see what else is needed.
 
- Get the full runtime classpath (so that I can "repl" against my project where thats feasible/makes sense)
I'd except you will be looking for compile classpath first. If you delegate build to Gradle you can delegate run/debug to it in many cases too and then runtime classpath is less important. Or am I missing the use case here? 

The truth is you will probably not get it now and the best is to use classpath generated as part of IdeaProject (getDependencies() in http://www.gradle.org/docs/current/javadoc/org/gradle/tooling/model/idea/IdeaModule.html). We want improve this and add a new dependency managment that will be accompanied with tooling support.
 
- And probably a whole host of other things when things mature
:-) 

My Gradle projects contains a really rich model, but my initial impression is that the tooling-api really only exposes a teeny-weeny fraction and it's very much geared towards the two big IDE's. I can appreciate why that might be the case, but I'd love to hear that the plan is to provide mechanisms to make it easy to suck out as much as possible of the rich model information of the gradle project model as possible :-)

It really feels wrong to retrieve an IdeaModel to get hold of my project dependencies. A generic GradleModel or JVMModel or whatever makes more sense to me for an API for common consumption (let IDEA/eclipse have their own plugin/api modules depending on a common tooling api module) !
I wouldn't worry about using IDEA model for the moment and things will move in the direction that you are suggestion later.

There are two other things that can be extremely useful for you: BuildActions (http://www.gradle.org/docs/current/javadoc/org/gradle/tooling/ProjectConnection.html#action(org.gradle.tooling.BuildAction) ) and custom model builders (http://www.gradle.org/docs/current/javadoc/org/gradle/tooling/provider/model/package-frame.html). Both of them give you chance to get additional information that is not part of existing APIs.

I might be a little uninformed. It does seem to be an option to create your own custom model, but I'm guessing that this must be a separate plugin that I then must "force" my projects to apply in order to be able to actually use it ?
One way is to create ProjectConnection that uses Gradle started with an init script that registers your own tooling model builder. AFAIK this is used in Idea and NetBeans plugins (I'm not sure about Eclipse).
 


I can summarize my wishes in two categories:
1. Invoking the build (and get much richer feedback than today: Test results, assertion errors, compilation errors etc etc)
2. Retrieve data from the richness of my defined gradle projects. Focus being on data ! For my usage strong typing, advanced hierarchies, interface/impl separations etc are not what I'm after. I wish to work on datastructures (maps, lists etc works a charm). However since I use groovy, class structures are usually not that much of a hassle. But if I for a custom model end up having to implement tons of dataholding only classes, then I wouldn't be a happy camper.
I think there is enough to begin with already and it is good to have this input and it can help us prioritize. You can create an API that fits your style with custom models so I hope you will find it sufficient.
 

I guess I'm starting to get damaged by working with Clojure and I fully comprehend that other (and much larger users) have other wishes/drivers


Reading through this:

Am I for off if I'm guessing that any hopes I would have of a rich generic GradleModel/JVMModel in the tooling api is probably not on the roadmap and my best bet would be to implement my own model ?
(I also fully appreciate that there are many dimensions to this when you factor in shipped and custom plugins, api changes, versioning etc etc.)
There are some other specs relevant to this topic like IDE integration or dependency managment (this one can miss its tooling aspects).

Now I have a question too: what are the typical projects that you expect your users to develop with your IDE/plugin?
 
-Radim


cheers for the great work with Gradle and  +1 to any endeavours for making the tooling api even cooler !

-magnus





Reply | Threaded
Open this post in threaded view
|

RE: tooling-api, the not idea/eclipse use case !

Magnus Rundberget-3
Thx for the swift and thorough reply !

A few comments/clarifications inline below (annotated with Magnus: due to crappy email client (: )

- Build my project (or invoke selectable build tasks)
That is possible right now and we did some improvements recently to give Tooling API clients better information about tasks and will continue the work in this direction.

Magnus: Yeah. Seems I can get pretty far with whats already there. Which is great.

- Continuously run tests (if I choose to)
- Test a single unit and preferably see test results inline in my editor
Cool. These two are related and it can be a bit tricky depending on what tests you actually want to run and how often. It is possible now but it is not so nice as I would like it to be and it is on our list of things to do.

Magnus: I'd love to be able to mimmic what I've done for a javascript plugin. Which is roughly: The editor automatically recognises whether a particular file is a test file (which should be possible through inspecting what is configured as test source directories). When I change and save a test file, it automatically triggers the test task with the filename(/pattern). The/a test progress reporter through the api notifies about test progress (ok, failures and errors). To be able show results inline I would at least need filename and test method names + status back. 

- continuously test I guess could be solved simplistically by blindly kicking of a test "all" task whenever I change a file belonging to a project in Light Table. 


 
- Visualize all the dependencies of my project (and their interdependencies)
You can use http://www.gradle.org/docs/current/javadoc/org/gradle/tooling/model/gradle/GradleBuild.html as a starting point and let's see what else is needed.

Magnus: That's cool for visualizing multiproject gradle project dependencies. I was thinking a step further, ie something more akin to the gradle dependencyReport. Light Table can show pretty much anything in an editor, so I was thinking maybe to visualize 3rd party dependencies (resolved through the gradle resolving strategy for the project) as drillable  d3 dotgraph :-)


- Get the full runtime classpath (so that I can "repl" against my project where thats feasible/makes sense)
I'd except you will be looking for compile classpath first. If you delegate build to Gradle you can delegate run/debug to it in many cases too and then runtime classpath is less important. Or am I missing the use case here? 

Magnus: Might be true in many cases, in my immediate need which is a groovy "repl" I really do need the runtime classpath (which would include any compiled classes etc) I think, because I create a groovyshell for each eval, do some funky ast stuff and evaluate the script and stores the results (bindings) to mimic a REPL. 


The truth is you will probably not get it now and the best is to use classpath generated as part of IdeaProject (getDependencies() in http://www.gradle.org/docs/current/javadoc/org/gradle/tooling/model/idea/IdeaModule.html). We want improve this and add a new dependency managment that will be accompanied with tooling support.

Magnus: This is what I've started with and it has certainly got me up and running already !
 
- And probably a whole host of other things when things mature
:-) 

My Gradle projects contains a really rich model, but my initial impression is that the tooling-api really only exposes a teeny-weeny fraction and it's very much geared towards the two big IDE's. I can appreciate why that might be the case, but I'd love to hear that the plan is to provide mechanisms to make it easy to suck out as much as possible of the rich model information of the gradle project model as possible :-)

It really feels wrong to retrieve an IdeaModel to get hold of my project dependencies. A generic GradleModel or JVMModel or whatever makes more sense to me for an API for common consumption (let IDEA/eclipse have their own plugin/api modules depending on a common tooling api module) !
I wouldn't worry about using IDEA model for the moment and things will move in the direction that you are suggestion later.

There are two other things that can be extremely useful for you: BuildActions (http://www.gradle.org/docs/current/javadoc/org/gradle/tooling/ProjectConnection.html#action(org.gradle.tooling.BuildAction) ) and custom model builders (http://www.gradle.org/docs/current/javadoc/org/gradle/tooling/provider/model/package-frame.html). Both of them give you chance to get additional information that is not part of existing APIs.

Magnus: Oh. The BuildAction thing passed me by. Cheers. Will investigate!


I might be a little uninformed. It does seem to be an option to create your own custom model, but I'm guessing that this must be a separate plugin that I then must "force" my projects to apply in order to be able to actually use it ?
One way is to create ProjectConnection that uses Gradle started with an init script that registers your own tooling model builder. AFAIK this is used in Idea and NetBeans plugins (I'm not sure about Eclipse).

Magnus: Yay. That sounds like a feasible route. Thx a bunch !
 


I can summarize my wishes in two categories:
1. Invoking the build (and get much richer feedback than today: Test results, assertion errors, compilation errors etc etc)
2. Retrieve data from the richness of my defined gradle projects. Focus being on data ! For my usage strong typing, advanced hierarchies, interface/impl separations etc are not what I'm after. I wish to work on datastructures (maps, lists etc works a charm). However since I use groovy, class structures are usually not that much of a hassle. But if I for a custom model end up having to implement tons of dataholding only classes, then I wouldn't be a happy camper.
I think there is enough to begin with already and it is good to have this input and it can help us prioritize. You can create an API that fits your style with custom models so I hope you will find it sufficient.

Magnus: It sounds like once I grock the custom models stuff I should be able to get pretty far :-)
 

I guess I'm starting to get damaged by working with Clojure and I fully comprehend that other (and much larger users) have other wishes/drivers


Reading through this:

Am I for off if I'm guessing that any hopes I would have of a rich generic GradleModel/JVMModel in the tooling api is probably not on the roadmap and my best bet would be to implement my own model ?
(I also fully appreciate that there are many dimensions to this when you factor in shipped and custom plugins, api changes, versioning etc etc.)
There are some other specs relevant to this topic like IDE integration or dependency managment (this one can miss its tooling aspects).

Now I have a question too: what are the typical projects that you expect your users to develop with your IDE/plugin?

Magnus: 
- My first goal is really to provide a powerful alternative to the Groovy Console. Being able to evaluate arbitrary groovy code in a REPL like fashion and see results inline. I've already come some way here, the next step (which is what I've just started on)  is to be able to evaluate groovy expressions with the classpath for any given gradle (jvm) project I might wish to explore in a repl like fashion. I've done a promising spike on this already.   Once hooked up to gradle for a project, well there is suddenly a lot of things that would be possible.

- I can imagine myself being able to use LightTable + plugins as a lightweight alternative to Intellij (which is really my primary day to day editor at the moment) for the kind of projects I'm involved in. And if I can use it, well then theres a chance others might find it useful and/or willing to contribute to making it useful for their projects.
What kind of projects: Well I mostly work on JVM webapps. I can see (hope) myself working on ratpack or vertx as basis for my next web project. Currently I work on a Grails project. There is a gradle plugin for grails, but we haven't actually used it. For Grails 3 I can imagine grails development outside IntelliJ/Eclipse to become completely feasible with a rich gradle integration.  For now I'm thinking I'd be doing it more to prove a point than being more productive though :-)

To summarize; I've just started on a journey which was initiated by a wish to learn about Light Table and idea of providing a more powerful groovy console. Maybe just maybe its feasible to actually provide enough support in Light Table through plugins to provide an appealing and maybe to some extent unique alternative to the "traditional" big IDE's for JVM projects.

who knows, but maybe it leads somewhere or maybe it'll just end up as a powerful console.  Maybe I'm helping paving the way for other editors/lightweight IDE's when it comes to jvm languages integration or maybe I'll just realize that there is just too many features you can't live without in a modern IDE :-)


Tx for your time. I'll keep you posted with any significant progress If you are interested :-) !

cheers
Magnus

 
-Radim


cheers for the great work with Gradle and  +1 to any endeavours for making the tooling api even cooler !

-magnus





Reply | Threaded
Open this post in threaded view
|

Re: tooling-api, the not idea/eclipse use case !

Radim Kubacki



On Sun, May 18, 2014 at 2:20 PM, Magnus Rundberget <[hidden email]> wrote:
Thx for the swift and thorough reply !

A few comments/clarifications inline below (annotated with Magnus: due to crappy email client (: )

- Build my project (or invoke selectable build tasks)
That is possible right now and we did some improvements recently to give Tooling API clients better information about tasks and will continue the work in this direction.

Magnus: Yeah. Seems I can get pretty far with whats already there. Which is great.

- Continuously run tests (if I choose to)
- Test a single unit and preferably see test results inline in my editor
Cool. These two are related and it can be a bit tricky depending on what tests you actually want to run and how often. It is possible now but it is not so nice as I would like it to be and it is on our list of things to do.

Magnus: I'd love to be able to mimmic what I've done for a javascript plugin. Which is roughly: The editor automatically recognises whether a particular file is a test file (which should be possible through inspecting what is configured as test source directories). When I change and save a test file, it automatically triggers the test task with the filename(/pattern). The/a test progress reporter through the api notifies about test progress (ok, failures and errors). To be able show results inline I would at least need filename and test method names + status back. 

Recognizing a test is probably the simpler part: Idea model has the information whether sources (content roots) belongs to a production or test sources. Or look for project tasks of type Test and their input sourceSet. Filter this to classes ending with Test/IT/Spec if you want to ignore fixtures, runners, helpers and others.

- continuously test I guess could be solved simplistically by blindly kicking of a test "all" task whenever I change a file belonging to a project in Light Table. 


 
- Visualize all the dependencies of my project (and their interdependencies)
You can use http://www.gradle.org/docs/current/javadoc/org/gradle/tooling/model/gradle/GradleBuild.html as a starting point and let's see what else is needed.

Magnus: That's cool for visualizing multiproject gradle project dependencies. I was thinking a step further, ie something more akin to the gradle dependencyReport. Light Table can show pretty much anything in an editor, so I was thinking maybe to visualize 3rd party dependencies (resolved through the gradle resolving strategy for the project) as drillable  d3 dotgraph :-)

Awesome. I'd love to see this! Actually I was thinking about a demo on exactly this stuff for a ToolingAPI talk - show how to get information about project dependencies or resolved dependencies and show it in some nice UI. D3 can probably do the UI part easily. 

- Get the full runtime classpath (so that I can "repl" against my project where thats feasible/makes sense)
I'd except you will be looking for compile classpath first. If you delegate build to Gradle you can delegate run/debug to it in many cases too and then runtime classpath is less important. Or am I missing the use case here? 

Magnus: Might be true in many cases, in my immediate need which is a groovy "repl" I really do need the runtime classpath (which would include any compiled classes etc) I think, because I create a groovyshell for each eval, do some funky ast stuff and evaluate the script and stores the results (bindings) to mimic a REPL. 

Interesting. Thanks for the explanation. 

The truth is you will probably not get it now and the best is to use classpath generated as part of IdeaProject (getDependencies() in http://www.gradle.org/docs/current/javadoc/org/gradle/tooling/model/idea/IdeaModule.html). We want improve this and add a new dependency managment that will be accompanied with tooling support.

Magnus: This is what I've started with and it has certainly got me up and running already !
 
- And probably a whole host of other things when things mature
:-) 

My Gradle projects contains a really rich model, but my initial impression is that the tooling-api really only exposes a teeny-weeny fraction and it's very much geared towards the two big IDE's. I can appreciate why that might be the case, but I'd love to hear that the plan is to provide mechanisms to make it easy to suck out as much as possible of the rich model information of the gradle project model as possible :-)

It really feels wrong to retrieve an IdeaModel to get hold of my project dependencies. A generic GradleModel or JVMModel or whatever makes more sense to me for an API for common consumption (let IDEA/eclipse have their own plugin/api modules depending on a common tooling api module) !
I wouldn't worry about using IDEA model for the moment and things will move in the direction that you are suggestion later.

There are two other things that can be extremely useful for you: BuildActions (http://www.gradle.org/docs/current/javadoc/org/gradle/tooling/ProjectConnection.html#action(org.gradle.tooling.BuildAction) ) and custom model builders (http://www.gradle.org/docs/current/javadoc/org/gradle/tooling/provider/model/package-frame.html). Both of them give you chance to get additional information that is not part of existing APIs.

Magnus: Oh. The BuildAction thing passed me by. Cheers. Will investigate!


I might be a little uninformed. It does seem to be an option to create your own custom model, but I'm guessing that this must be a separate plugin that I then must "force" my projects to apply in order to be able to actually use it ?
One way is to create ProjectConnection that uses Gradle started with an init script that registers your own tooling model builder. AFAIK this is used in Idea and NetBeans plugins (I'm not sure about Eclipse).

Magnus: Yay. That sounds like a feasible route. Thx a bunch !
 


I can summarize my wishes in two categories:
1. Invoking the build (and get much richer feedback than today: Test results, assertion errors, compilation errors etc etc)
2. Retrieve data from the richness of my defined gradle projects. Focus being on data ! For my usage strong typing, advanced hierarchies, interface/impl separations etc are not what I'm after. I wish to work on datastructures (maps, lists etc works a charm). However since I use groovy, class structures are usually not that much of a hassle. But if I for a custom model end up having to implement tons of dataholding only classes, then I wouldn't be a happy camper.
I think there is enough to begin with already and it is good to have this input and it can help us prioritize. You can create an API that fits your style with custom models so I hope you will find it sufficient.

Magnus: It sounds like once I grock the custom models stuff I should be able to get pretty far :-)
 

I guess I'm starting to get damaged by working with Clojure and I fully comprehend that other (and much larger users) have other wishes/drivers


Reading through this:

Am I for off if I'm guessing that any hopes I would have of a rich generic GradleModel/JVMModel in the tooling api is probably not on the roadmap and my best bet would be to implement my own model ?
(I also fully appreciate that there are many dimensions to this when you factor in shipped and custom plugins, api changes, versioning etc etc.)
There are some other specs relevant to this topic like IDE integration or dependency managment (this one can miss its tooling aspects).

Now I have a question too: what are the typical projects that you expect your users to develop with your IDE/plugin?

Magnus: 
- My first goal is really to provide a powerful alternative to the Groovy Console. Being able to evaluate arbitrary groovy code in a REPL like fashion and see results inline. I've already come some way here, the next step (which is what I've just started on)  is to be able to evaluate groovy expressions with the classpath for any given gradle (jvm) project I might wish to explore in a repl like fashion. I've done a promising spike on this already.   Once hooked up to gradle for a project, well there is suddenly a lot of things that would be possible.

- I can imagine myself being able to use LightTable + plugins as a lightweight alternative to Intellij (which is really my primary day to day editor at the moment) for the kind of projects I'm involved in. And if I can use it, well then theres a chance others might find it useful and/or willing to contribute to making it useful for their projects.
What kind of projects: Well I mostly work on JVM webapps. I can see (hope) myself working on ratpack or vertx as basis for my next web project. Currently I work on a Grails project. There is a gradle plugin for grails, but we haven't actually used it. For Grails 3 I can imagine grails development outside IntelliJ/Eclipse to become completely feasible with a rich gradle integration.  For now I'm thinking I'd be doing it more to prove a point than being more productive though :-)

To summarize; I've just started on a journey which was initiated by a wish to learn about Light Table and idea of providing a more powerful groovy console. Maybe just maybe its feasible to actually provide enough support in Light Table through plugins to provide an appealing and maybe to some extent unique alternative to the "traditional" big IDE's for JVM projects.

who knows, but maybe it leads somewhere or maybe it'll just end up as a powerful console.  Maybe I'm helping paving the way for other editors/lightweight IDE's when it comes to jvm languages integration or maybe I'll just realize that there is just too many features you can't live without in a modern IDE :-)


Tx for your time. I'll keep you posted with any significant progress If you are interested :-) !

Definitely keep us in the loop. I like this approach and IMO opens a way for other types of projects developed with tools where a lighter integration than current Eclipse/Idea can help developers to get their job done.

-Radim

cheers
Magnus

 
-Radim


cheers for the great work with Gradle and  +1 to any endeavours for making the tooling api even cooler !

-magnus






Reply | Threaded
Open this post in threaded view
|

Re: tooling-api, the not idea/eclipse use case !

Adam Murdoch
In reply to this post by Magnus Rundberget-3

On 16 May 2014, at 5:20 pm, Magnus Rundberget <[hidden email]> wrote:

Hi !

I'm currently working on creating a gradle/groovy plugin for the Light Table editor (more texteditor than IDE). I haven't spent that much time getting to now the API and what you can do. But I do have some (perhaps premature) observations and questions though :-)
Before I start I'd like to state it's great to have the api in the first place and I appreciate the commitment to backwards compatibility !

My use cases/wishes:
I don't wish to replicate IntelliJ or Eclipse (or Netbeans) in any way shape or form. But I do wish to be able to edit my projects in a lightweight super hackable editor and still be able to do things like:
- Anything that has to do with building is handled by the gradle
- Build my project (or invoke selectable build tasks)
- Continuously run tests (if I choose to)
- Test a single unit and preferably see test results inline in my editor
- Visualize all the dependencies of my project (and their interdependencies)
- Get the full runtime classpath (so that I can "repl" against my project where thats feasible/makes sense)
- And probably a whole host of other things when things mature

My Gradle projects contains a really rich model, but my initial impression is that the tooling-api really only exposes a teeny-weeny fraction and it's very much geared towards the two big IDE's. I can appreciate why that might be the case, but I'd love to hear that the plan is to provide mechanisms to make it easy to suck out as much as possible of the rich model information of the gradle project model as possible :-)

It really feels wrong to retrieve an IdeaModel to get hold of my project dependencies. A generic GradleModel or JVMModel or whatever makes more sense to me for an API for common consumption (let IDEA/eclipse have their own plugin/api modules depending on a common tooling api module) !

I might be a little uninformed. It does seem to be an option to create your own custom model, but I'm guessing that this must be a separate plugin that I then must "force" my projects to apply in order to be able to actually use it ?


I can summarize my wishes in two categories:
1. Invoking the build (and get much richer feedback than today: Test results, assertion errors, compilation errors etc etc)
2. Retrieve data from the richness of my defined gradle projects. Focus being on data ! For my usage strong typing, advanced hierarchies, interface/impl separations etc are not what I'm after. I wish to work on datastructures (maps, lists etc works a charm). However since I use groovy, class structures are usually not that much of a hassle. But if I for a custom model end up having to implement tons of dataholding only classes, then I wouldn't be a happy camper.

I guess I'm starting to get damaged by working with Clojure and I fully comprehend that other (and much larger users) have other wishes/drivers


Reading through this:

Am I for off if I'm guessing that any hopes I would have of a rich generic GradleModel/JVMModel in the tooling api is probably not on the roadmap and my best bet would be to implement my own model ?

I would say it is on the roadmap, to have some IDE agnostic models available through the tooling API. I’d rather have something more strongly typed than you describe, but let’s see.

Would you be interested in helping out to add these models?


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

Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com

Reply | Threaded
Open this post in threaded view
|

RE: tooling-api, the not idea/eclipse use case !

Magnus Rundberget-3
Hi !

For an official shipped tooling API i totally agree on the strong typing part. It was more in terms of if I were to go down the road of implementing my own custom model plugin. Then I'd probably go for a fairly loosely typed flavour :-) 

Contributing ?
- If I (and you guys) feel I can add value and time permits I'm certainly positive. Let me get back to you after gr8conf.eu (next week). 


cheers
Magnus




From: [hidden email]
Date: Thu, 22 May 2014 09:20:13 -0400
To: [hidden email]
Subject: Re: [gradle-dev] tooling-api, the not idea/eclipse use case !


On 16 May 2014, at 5:20 pm, Magnus Rundberget <[hidden email]> wrote:

Hi !

I'm currently working on creating a gradle/groovy plugin for the Light Table editor (more texteditor than IDE). I haven't spent that much time getting to now the API and what you can do. But I do have some (perhaps premature) observations and questions though :-)
Before I start I'd like to state it's great to have the api in the first place and I appreciate the commitment to backwards compatibility !

My use cases/wishes:
I don't wish to replicate IntelliJ or Eclipse (or Netbeans) in any way shape or form. But I do wish to be able to edit my projects in a lightweight super hackable editor and still be able to do things like:
- Anything that has to do with building is handled by the gradle
- Build my project (or invoke selectable build tasks)
- Continuously run tests (if I choose to)
- Test a single unit and preferably see test results inline in my editor
- Visualize all the dependencies of my project (and their interdependencies)
- Get the full runtime classpath (so that I can "repl" against my project where thats feasible/makes sense)
- And probably a whole host of other things when things mature

My Gradle projects contains a really rich model, but my initial impression is that the tooling-api really only exposes a teeny-weeny fraction and it's very much geared towards the two big IDE's. I can appreciate why that might be the case, but I'd love to hear that the plan is to provide mechanisms to make it easy to suck out as much as possible of the rich model information of the gradle project model as possible :-)

It really feels wrong to retrieve an IdeaModel to get hold of my project dependencies. A generic GradleModel or JVMModel or whatever makes more sense to me for an API for common consumption (let IDEA/eclipse have their own plugin/api modules depending on a common tooling api module) !

I might be a little uninformed. It does seem to be an option to create your own custom model, but I'm guessing that this must be a separate plugin that I then must "force" my projects to apply in order to be able to actually use it ?


I can summarize my wishes in two categories:
1. Invoking the build (and get much richer feedback than today: Test results, assertion errors, compilation errors etc etc)
2. Retrieve data from the richness of my defined gradle projects. Focus being on data ! For my usage strong typing, advanced hierarchies, interface/impl separations etc are not what I'm after. I wish to work on datastructures (maps, lists etc works a charm). However since I use groovy, class structures are usually not that much of a hassle. But if I for a custom model end up having to implement tons of dataholding only classes, then I wouldn't be a happy camper.

I guess I'm starting to get damaged by working with Clojure and I fully comprehend that other (and much larger users) have other wishes/drivers


Reading through this:

Am I for off if I'm guessing that any hopes I would have of a rich generic GradleModel/JVMModel in the tooling api is probably not on the roadmap and my best bet would be to implement my own model ?

I would say it is on the roadmap, to have some IDE agnostic models available through the tooling API. I’d rather have something more strongly typed than you describe, but let’s see.

Would you be interested in helping out to add these models?


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

Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com

Reply | Threaded
Open this post in threaded view
|

RE: tooling-api, the not idea/eclipse use case !

Magnus Rundberget-3
sorry for the delayed feedback, got carried away with implementing a custom gradle model. Worked like a charm. Really cool!  So my Light Table groovy(/gradle) plugin can retrieve the runtime classpath and detailed info about dependencies to display a dependency graph.

With regards to contributing, I'd be interested. How to proceed ? I guess some level of up front design would make sense.

cheers
Magnus





From: [hidden email]
To: [hidden email]
Date: Mon, 26 May 2014 18:25:18 +0200
Subject: RE: [gradle-dev] tooling-api, the not idea/eclipse use case !

Hi !

For an official shipped tooling API i totally agree on the strong typing part. It was more in terms of if I were to go down the road of implementing my own custom model plugin. Then I'd probably go for a fairly loosely typed flavour :-) 

Contributing ?
- If I (and you guys) feel I can add value and time permits I'm certainly positive. Let me get back to you after gr8conf.eu (next week). 


cheers
Magnus




From: [hidden email]
Date: Thu, 22 May 2014 09:20:13 -0400
To: [hidden email]
Subject: Re: [gradle-dev] tooling-api, the not idea/eclipse use case !


On 16 May 2014, at 5:20 pm, Magnus Rundberget <[hidden email]> wrote:

Hi !

I'm currently working on creating a gradle/groovy plugin for the Light Table editor (more texteditor than IDE). I haven't spent that much time getting to now the API and what you can do. But I do have some (perhaps premature) observations and questions though :-)
Before I start I'd like to state it's great to have the api in the first place and I appreciate the commitment to backwards compatibility !

My use cases/wishes:
I don't wish to replicate IntelliJ or Eclipse (or Netbeans) in any way shape or form. But I do wish to be able to edit my projects in a lightweight super hackable editor and still be able to do things like:
- Anything that has to do with building is handled by the gradle
- Build my project (or invoke selectable build tasks)
- Continuously run tests (if I choose to)
- Test a single unit and preferably see test results inline in my editor
- Visualize all the dependencies of my project (and their interdependencies)
- Get the full runtime classpath (so that I can "repl" against my project where thats feasible/makes sense)
- And probably a whole host of other things when things mature

My Gradle projects contains a really rich model, but my initial impression is that the tooling-api really only exposes a teeny-weeny fraction and it's very much geared towards the two big IDE's. I can appreciate why that might be the case, but I'd love to hear that the plan is to provide mechanisms to make it easy to suck out as much as possible of the rich model information of the gradle project model as possible :-)

It really feels wrong to retrieve an IdeaModel to get hold of my project dependencies. A generic GradleModel or JVMModel or whatever makes more sense to me for an API for common consumption (let IDEA/eclipse have their own plugin/api modules depending on a common tooling api module) !

I might be a little uninformed. It does seem to be an option to create your own custom model, but I'm guessing that this must be a separate plugin that I then must "force" my projects to apply in order to be able to actually use it ?


I can summarize my wishes in two categories:
1. Invoking the build (and get much richer feedback than today: Test results, assertion errors, compilation errors etc etc)
2. Retrieve data from the richness of my defined gradle projects. Focus being on data ! For my usage strong typing, advanced hierarchies, interface/impl separations etc are not what I'm after. I wish to work on datastructures (maps, lists etc works a charm). However since I use groovy, class structures are usually not that much of a hassle. But if I for a custom model end up having to implement tons of dataholding only classes, then I wouldn't be a happy camper.

I guess I'm starting to get damaged by working with Clojure and I fully comprehend that other (and much larger users) have other wishes/drivers


Reading through this:

Am I for off if I'm guessing that any hopes I would have of a rich generic GradleModel/JVMModel in the tooling api is probably not on the roadmap and my best bet would be to implement my own model ?

I would say it is on the roadmap, to have some IDE agnostic models available through the tooling API. I’d rather have something more strongly typed than you describe, but let’s see.

Would you be interested in helping out to add these models?


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

Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com

Reply | Threaded
Open this post in threaded view
|

Re: tooling-api, the not idea/eclipse use case !

Radim Kubacki
On Wed, Jun 18, 2014 at 7:16 AM, Magnus Rundberget <[hidden email]> wrote:
sorry for the delayed feedback, got carried away with implementing a custom gradle model. Worked like a charm. Really cool!  So my Light Table groovy(/gradle) plugin can retrieve the runtime classpath and detailed info about dependencies to display a dependency graph.

Nice, I've seen your tweet earlier and it looks good :-)
 
With regards to contributing, I'd be interested. How to proceed ? I guess some level of up front design would make sense.

https://github.com/gradle/gradle/blob/master/CONTRIBUTING.md summarizes some legal stuff and has a high level overview of the process. Our design specs are in https://github.com/gradle/gradle/tree/master/design-docs and that's usually the first thing to do. I see that you have started another thread to start the technical discussion.

-Radim
cheers
Magnus





From: [hidden email]
To: [hidden email]
Date: Mon, 26 May 2014 18:25:18 +0200
Subject: RE: [gradle-dev] tooling-api, the not idea/eclipse use case !


Hi !

For an official shipped tooling API i totally agree on the strong typing part. It was more in terms of if I were to go down the road of implementing my own custom model plugin. Then I'd probably go for a fairly loosely typed flavour :-) 

Contributing ?
- If I (and you guys) feel I can add value and time permits I'm certainly positive. Let me get back to you after gr8conf.eu (next week). 


cheers
Magnus




From: [hidden email]
Date: Thu, 22 May 2014 09:20:13 -0400
To: [hidden email]
Subject: Re: [gradle-dev] tooling-api, the not idea/eclipse use case !


On 16 May 2014, at 5:20 pm, Magnus Rundberget <[hidden email]> wrote:

Hi !

I'm currently working on creating a gradle/groovy plugin for the Light Table editor (more texteditor than IDE). I haven't spent that much time getting to now the API and what you can do. But I do have some (perhaps premature) observations and questions though :-)
Before I start I'd like to state it's great to have the api in the first place and I appreciate the commitment to backwards compatibility !

My use cases/wishes:
I don't wish to replicate IntelliJ or Eclipse (or Netbeans) in any way shape or form. But I do wish to be able to edit my projects in a lightweight super hackable editor and still be able to do things like:
- Anything that has to do with building is handled by the gradle
- Build my project (or invoke selectable build tasks)
- Continuously run tests (if I choose to)
- Test a single unit and preferably see test results inline in my editor
- Visualize all the dependencies of my project (and their interdependencies)
- Get the full runtime classpath (so that I can "repl" against my project where thats feasible/makes sense)
- And probably a whole host of other things when things mature

My Gradle projects contains a really rich model, but my initial impression is that the tooling-api really only exposes a teeny-weeny fraction and it's very much geared towards the two big IDE's. I can appreciate why that might be the case, but I'd love to hear that the plan is to provide mechanisms to make it easy to suck out as much as possible of the rich model information of the gradle project model as possible :-)

It really feels wrong to retrieve an IdeaModel to get hold of my project dependencies. A generic GradleModel or JVMModel or whatever makes more sense to me for an API for common consumption (let IDEA/eclipse have their own plugin/api modules depending on a common tooling api module) !

I might be a little uninformed. It does seem to be an option to create your own custom model, but I'm guessing that this must be a separate plugin that I then must "force" my projects to apply in order to be able to actually use it ?


I can summarize my wishes in two categories:
1. Invoking the build (and get much richer feedback than today: Test results, assertion errors, compilation errors etc etc)
2. Retrieve data from the richness of my defined gradle projects. Focus being on data ! For my usage strong typing, advanced hierarchies, interface/impl separations etc are not what I'm after. I wish to work on datastructures (maps, lists etc works a charm). However since I use groovy, class structures are usually not that much of a hassle. But if I for a custom model end up having to implement tons of dataholding only classes, then I wouldn't be a happy camper.

I guess I'm starting to get damaged by working with Clojure and I fully comprehend that other (and much larger users) have other wishes/drivers


Reading through this:

Am I for off if I'm guessing that any hopes I would have of a rich generic GradleModel/JVMModel in the tooling api is probably not on the roadmap and my best bet would be to implement my own model ?

I would say it is on the roadmap, to have some IDE agnostic models available through the tooling API. I’d rather have something more strongly typed than you describe, but let’s see.

Would you be interested in helping out to add these models?


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

Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com