buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexis Midon" <mi...@apache.org>
Subject Re: Better error messages and Growl notifications
Date Mon, 28 Jul 2008 23:52:43 GMT
well, in addition why not but if you're rephrasing my proposal I would say I
feel more safe with the real java/javac commands so I can check all options,
etc and might even want to reuse it .



On Mon, Jul 28, 2008 at 3:29 PM, Assaf Arkin <arkin@intalio.com> wrote:

> On Mon, Jul 28, 2008 at 12:31 PM, Alexis Midon <alexismidon@gmail.com>
> wrote:
> > one thing I was thinking of while debugging some classpath issues is that
> > it's kind of a pain to get all the verbose ruby traces just to get the
> > java/javac commands executed by buildr.
> >
> > How would you like an option to get only the java/javac output? or a less
> > verbose trace option?
>
> How about a feature that dumps that just dumps the dependency lists
> and nothing else?
>
> Assaf
>
> >
> >
> > On Mon, Jul 28, 2008 at 9:09 AM, Assaf Arkin <arkin@intalio.com> wrote:
> >
> >> On Mon, Jul 28, 2008 at 4:41 AM, lacton <lacton@users.sourceforge.net>
> >> wrote:
> >> > On Fri, Jul 25, 2008 at 2:02 AM, Assaf Arkin <arkin@intalio.com>
> wrote:
> >> >> I want to know if they make your life better, just plan annoying, and
> >> >> any ideas for making them even better.
> >> >>
> >> >>
> >> >> ==  Stack trace
> >> > [...]
> >> >> I'm toying around with making this a bit better, the latest change
> >> >> will show any number of lines (usually just one) from the buildfile.
> >> >> If you want to help find the right balance between two much
> >> >> information and not enough, have a look at the
> >> >> standard_exception_handling method in lib/buildr/core/application.rb
> >> >
> >> > +1 for me.
> >> >
> >> > Showing all concerned buildfile's lines even when not running with
> >> > --trace saves time without crowding the screen too much. Most of the
> >> > time, there is only one line to display anyway, but when there is two
> >> > lines to show, I find it's usually a precious piece of information.
> >> >
> >> >> == Colors for errors
> >> >>
> >> >> I think it's a good idea to use a splash of color for salient
> >> >> information.  So I started by making error messages show up in red,
> >> >> that way they're noticeable when you run Buildr from the console
> >> >> (warnings are now blue).  Any ideas on how to use colors more
> >> >> effectively?
> >> >
> >> > I like your use of color. Could you give me an example of a blue
> message?
> >>
> >> Right now we use warnings in three places.  Deprecated warnings, for
> >> every deprecated method or feature.  In a few places, where we're not
> >> sure it's an error but worth paying attention.  For example, if you
> >> run buildr package in a directory not associated with any project, it
> >> warns you that "No projects defined for directory ...", but it still
> >> runs that task -- it might do some other interesting things.
> >>
> >> The third place, a warning lists all the failed test cases for a
> >> project.  Typically, you'll also get an error message, unless you're
> >> running with test=all, in which case it will keep running test cases
> >> for other projects, so you can pick up these warnings from the
> >> console.  Although, maybe these should show as errors instead of
> >> warnings?
> >>
> >>
> >> > What would you think of making these facilities available to buildr
> >> > users? As a user, I would like to be able to log messages in a way
> >> > that is consistent with buildr. I imagine four methods:
> >> > trace "a message that will be displayed only if --trace option
> enabled"
> >> > info "a message that will be displayed every time"
> >> > warn "a message that will be displayed every time, in blue"
> >> > error "a message that will be displayed every time, in red"
> >>
> >> I like that.
> >>
> >> > Or maybe the last one should be merged with the 'fail' method.
> >>
> >> I think there's a reason to have both error and fail.  Specifically,
> >> the test=all option allows you to run all the test cases, ignoring
> >> errors, so there's no failure, but you'll still want to see these
> >> error messages.
> >>
> >> Assaf
> >>
> >> >
> >> > Lacton
> >> >
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message