On 24/03/2012, at 12:50 PM, Rene Groeschke wrote: > Hey guys, > > Today, I've pushed a change of the FindBugsPlugin, where the findbugs task is > executed in a separated worker process. These changes are related to > GRADLE-2167 (command line length limitations on windows). > As a orientation for this, I've used the compilerdaemon stuff. At the moment, > I haven't touched anything at the compilerdaemon related code. I'll take a > look on how we might abstract some of the FindBugs-daemon and the > Compiler-daemon stuff to a higher level as soon as I am happy with the > findbugs stuff. But before getting happy with this, I have some questions: > > 1. Is there any support for handling System - IN / OUT / ERR in the worker > process? ATM, I've redirected them manually just before executing findbugs > and then setting them back. The reason for that is, that I would like to add > a listener on the find bugs output to handle logging properly.
You'd use a LoggingManager. It would need to be exposed via the WorkerProcessContext. I think rather than messing with the logging, a better option might be to drive the findbugs API, and ask it if there were any failures. > > 2. I tend to use the workerprocess for executing findbugs as a default. What > do you think? Would it make sense for you to differ here on OS, commandline > length etc? The find bugs anttask we used before was starting a forking a > process anyway. If we don't differ here and use the workerprocess always, we > can get rid of the ant task in the findbugs configuration. Not sure what you mean here. > > 3. The lifecycle of the findbugs daemon. From my point of view I see two > reasonable options here: > a) once the findbugs worker process is started, we stop this daemon at > the build and reuse this process for other findbugs tasks (as implemented in > the compiler daemon) > b) stop the worker process after the task has finished. > > If you have a small build, you might have only one findbugs task, so the > process, that is kept open is just needless for the rest of the build. For > multi project builds, you normally would have multiple findbugs tasks. As > long as those tasks use the same findbugs version (I would expect, that this > is the case in 99% ), the daemon can be reused and the overhead for > forking/restarting findbugs can be reduced. While writing this, another > option comes in my mind: > b2) We can check, if the DAG has more findbugs tasks to execute, so we can > stop the findbugs process after the last findbugs task in the DAG is executed. We want b) for now. The task should start the child process, wait for it to finish its work, and then stop the child process. At some point later, we might generalise the process reuse stuff, but only once we can consider the contents of the task graph (your b2 above), and probably also schedule the findbugs tasks so that they are as close together as possible in the graph. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
