On Wed, Jun 18, 2014 at 7:16 AM, Magnus Rundberget <mrundber...@hotmail.com> 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: 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). > > > cheers > Magnus > > > > ------------------------------ > 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 > >
