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 <mrundber...@hotmail.com > 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.htmlas 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: > > https://github.com/gradle/gradle/blob/master/design-docs/tooling-api-improvements.md > > 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 > > > > >
