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
