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. - 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.html as 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 :-) - 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. 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 :-) ! cheersMagnus -Radim cheers for the great work with Gradle and +1 to any endeavours for making the tooling api even cooler ! -magnus
