--- On Fri, 5/8/09, Adam Murdoch <[email protected]> wrote:
> From: Adam Murdoch <[email protected]>
> Subject: Re: [gradle-dev] Feedback wanted on Gradle UI for future Idea plugin
> To: [email protected]
> Date: Friday, May 8, 2009, 9:44 PM
>
>
>
>
>
>
>
>
>
>
> 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.
>
Making it part of the output would probably be the best choice. It does mean
the error message is tied to the output, but you're likely to need to look at
the output anyway.
>
>
>
> 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
>
>
I finally tracked down my problem with duplicate output. It had to do with
Logback appender filters. I wasn't setting them up and was getting lots of
extraneous output. To solve this, I basically copied
org.gradle.initialization.DefaultLoggingConfigurer.configure() and modified it
to work with my appender. That function appears to be creating filters for
converting gradle log levels to Logback log levels.
With respect to what would I like, I'm fine with using the Logback mechanism,
but it would be nice if much of the code in
DefaultLoggingConfigurer.configure() were pulled out into a separate function
so others can make use of that functionality without duplicating it. I'm only
referring to the code that sets up the filters.
Mike
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
