Mike wrote:
Adam, In response to
3) Very minor, but some of the code in BuildExceptionReporter could made more
modular so that others can format gradle errors in the same way. The formatting
of errors there is using the OptionSet (which seems catered to command lines)
as well as assuming that your using this BuildListener. I ended up copying and
pasting much of that code. Its not a alot of code or complicated, but its
something I think any tool would want access to.
4) Getting access to gradle's output was a little problematic. Mostly, it was
just learning to use Logback, but I'm getting an oddity where some of the
output is duplicated, but not all. I haven't looked into this much, so I could
be using the API incorrectly, but I thought what I did was fairly
straightforward and this seems like something anyone accessing embedded gradle
would need to do.
What do you need to be able to do here?
Number 3 and 4 are related to the fact that I'm trying to show the same output
that 'command line' gradle shows (in the lower window). This is useful (or the
only) information for tracking down problems in the build process.
For number 3: If an exception occurs that causes the build to fail, I want to
report it in the same manner gradle does. This is more than just
Exception.getMessage(). There's logic for determining your 'stacktrace level'
and calling StackTraceUtils.deepSanitize() as well as a check for
GradleScriptException explicitly. Not a ton of functionality, but something
that any tool would be duplicating and could potentially get out of synch.
Perhaps this message should be treated as part of the textual output of
the build, rather than part of the embedding application.
Number 4 is related to how to latch onto gradle's current textual output and
showing it as the output occurs. Essentially, this amounts to adding a Logback
appender (which is what I did), but I'm getting some lines duplicated, but most
are working correctly. While I might have a bug in my code causing the
duplicates, it concerns me that such a simple thing is susceptible to such a
bug.
Do you know what's being duplicated? eg a particular log level? a
particular category? messages from Gradle itself, or redirected ivy, ant
or stdout messages?
It seems like any tool would need access to gradle's output, and since this is
used for tracking down build problems, it needs to be highly accurate. I would
prefer to add an output listener to gradle that just hands the text back to me
(as it occurs), shielding me from the details of Logback.
How would you like this to look? Some options:
* You provide a Writer which receives the text which would be written to
stdout/stderr as a stream of text. Perhaps separate Writers for stdout
and stderr.
* You provide a listener which receives each log message as a String,
possibly with some meta-info like severity and category.
* You provide an slf4j Logger, or java.util.Logger, or logback Appender,
or ...
Adam
