On Sun, May 18, 2014 at 2:20 PM, Magnus Rundberget <mrundber...@hotmail.com>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.htmlas > 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: > > 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? > > 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 > > > > > >
