buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Better error messages and Growl notifications
Date Wed, 30 Jul 2008 01:20:26 GMT
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
View raw message