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 Wed, 30 Jul 2008 18:17:40 GMT
thank you Assaf :)

On Tue, Jul 29, 2008 at 6:20 PM, Assaf Arkin <arkin@intalio.com> wrote:

> On Mon, Jul 28, 2008 at 8:33 PM, Alexis Midon <alexismidon@gmail.com>
> wrote:
> > well, even if different levels of verbosity won't make an Enterprise
> > edition, I agree that a good old grep makes the job.
> > I still have some linux conditioned reflexes to get.
>
> http://articles.techrepublic.com.com/5100-10878_11-1047762.html
>
> Assaf
>
> >
> >
> > On Mon, Jul 28, 2008 at 6:42 PM, Assaf Arkin <arkin@intalio.com> wrote:
> >
> >> On Mon, Jul 28, 2008 at 4:52 PM, Alexis Midon <midon@apache.org> wrote:
> >> > 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 .
> >>
> >> Not rephrasing, just offering a more practical solution to figure out
> >> dependency problems.  And to get the java(c) command line in all its
> >> glory:
> >>
> >> nohup buildr --trace  | grep ^java
> >>
> >> Adding all sorts of knobs and switches into Buildr sounds compelling,
> >> but if we end up delivering Buildr Team Server Enterprise Edition Pro,
> >> I think we'll failed our goal.  So I'm looking to exhaust all the
> >> other options first.
> >>
> >> Assaf
> >>
> >> >
> >> >
> >> >
> >> > 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