thank you Assaf :) On Tue, Jul 29, 2008 at 6:20 PM, Assaf Arkin <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 28, 2008 at 8:33 PM, Alexis Midon <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> wrote: > > > >> On Mon, Jul 28, 2008 at 4:52 PM, Alexis Midon <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > wrote: > >> > > >> >> On Mon, Jul 28, 2008 at 12:31 PM, Alexis Midon < > [EMAIL PROTECTED]> > >> >> 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 <[EMAIL PROTECTED]> > >> wrote: > >> >> > > >> >> >> On Mon, Jul 28, 2008 at 4:41 AM, lacton < > >> [EMAIL PROTECTED]> > >> >> >> wrote: > >> >> >> > On Fri, Jul 25, 2008 at 2:02 AM, Assaf Arkin <[EMAIL PROTECTED] > > > >> >> 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 > >> >> >> > > >> >> >> > >> >> > > >> >> > >> > > >> > > >
