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.
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.
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.
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.
As always, any pointers, ideas and suggestions are very much
appreciated.
regards,
René
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
