Gradle tooling api wishes

(Andreas Sahlbach) #1


I created some kind of port of the jetty plugin using a jetty based on the eclipse generation. You can find the project here: I changed a lot in this plugin to adapt it more to gradle. The plugin features backgound builds using the tooling api. Because of this, I came up with some requirements, that would make my plugin better. So here they are:

  1. Provide a way to use the tooling api without spoiling stdout and stderr. I am aware that I can add a listener to stdout and stderr, but the output still goes to the console. I would like to grab stdout and stderr exclusively to put my background builds really into the background. The user shouldn’t be bothered by them.

  2. Provide a way to ‘exclude’ build tasks like you can do it from command line with ‘-x’

  3. Provide a way to get information regarding the build that is more reliable than parsing stdout or stderr. In my case it would be very interesting to know, if tasks really did something or were just skipped because they were up-to-date.

  4. The last one isn’t really tooling api, but anyway: Provide a way to check the type of task dependencies. In my case, I am searching for a task dependency of type War (to use the output to start jetty). I couldn’t find an easy way to check for the type of a dependency. If there is a groovy way to do it, please tell me.

I think that’s it… :slight_smile:



(Attila Kelemen) #2
  1. I have nothing to add for this :slight_smile: 2. Using ‘withArguments(’-x’, ‘test’)’ will skip “test” task, if that’s what you mean. 3. We have already talked about this with Adam, that it would be good if the build could report something else back than a string progress. Currently, the only thing you can do is parsing stdout (even though this method is somewhat fragile). 4. I don’t know any other way but to traverse the task graph and test the types of the task. However, listing the task dependencies has some considerable performance overhead.

(Andreas Sahlbach) #3

Thanks for point 2. I’ve overseen this possibility, should be good for the plugin.

For point 4: My problem is not traversing the task dependencies. My question is: how to you actually test the type of a task? The object you get is a decorated class and “instanceof” didn’t work for me. Or do you think instanceof should work?

Here is the snippet I am currently using: The purpose is to find a War task that my task depends on.

warTask = null
        def warTasks = project.tasks.withType(War)
        for (dep in dependsOn) {
            if(dep instanceof String) {
                Task task = project.getTasksByName(dep,false).iterator().next()
                if(warTasks.contains(task)) {
                    warTask = task as War
        logger.debug("warTask used: $warTask")

That doesn’t look very elegant in my eyes. I would be glad if you could tell me how to improve that.

(Attila Kelemen) #4

I believe that getDependsOn() returns many kinds of possible types, you can’t really rely on that being a string.

I remember doing something similar in the past but I haven’t tested the following snipet. Regardless, something like this should work:

List getWarDependencies(Task task) {
    List result = new LinkedList();
    task.taskDependencies.getDependencies(task).each { dep ->
        if (dep instanceof War) {
    return result;

(Andreas Sahlbach) #5

Thanks, that worked. I tried this before, but I messed it up somehow (prolly because it was in the beginning of my groovy development :slight_smile:

So my wished are now reduced to 1) and 3) :wink: