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. cheersMagnus
From: mrundber...@hotmail.com To: dev@gradle.codehaus.org 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). cheersMagnus From: adam.murd...@gradleware.com Date: Thu, 22 May 2014 09:20:13 -0400 To: dev@gradle.codehaus.org Subject: Re: [gradle-dev] tooling-api, the not idea/eclipse use case ! On 16 May 2014, at 5: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- 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: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 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
