I have been a big fan of domained logging...where the logging api call
contains whatever is necessary to earmark that log message as belonging to a
particular domain (domain being whatever you want to define it as, the
class, the package, the logical functionality of something..)
I have done this before with something akin to
getLog().log("foo", Domain.REPO);
where REPO is a short or a long constant defined in the Domain object. I
don't think that would work for our purposes since we are hiding the logging
classes from a mojo for instance...
getLog().domain("foo", "repo");
might work, and have some dynamic process in the logging that registers new
logging domains on the fly. In log4j I just made the domain be their own
logger instance with custom appenders...in maven they could be shoved out to
the console marked as [REPO] in the log message so you can easily grep
through for those logging outputs. It is probably overkill to make seperate
logging files for each domain, but domained logging to one output file
toggled by a flag, coupled with the [FOO] distingishers would take care of
the problem I think..
jesse
On 1/11/06, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> Hi John,
>
> I think we'd all agree with the sentiment. I think the default needs to
> be less noisy, and -X should be targetted (debug artifact resolution,
> debug pom, etc). We could name systems and log accordingly. This is all
> in JIRA.
>
> If you have any suggestions for implementation, please say so!
>
> Cheers,
> Brett
>
> John Allen wrote:
> > Thoughts on logging:-
> >
> > I would like to see logging messages use relevant and meaningful
> > identifiers that are correlatable to provide users with a means of
> > knowing what is going on and what sequence of events has brought about
> > the output. Currently huge amounts of work goes on 'behind the scenes'
> > that results in lots of messages being produced long before there's any
> > mention of what phase or plugin goal has caused the messages or where
> > the user is in the flow of things. One of the biggest draw backs with
> > using maven 2, beyond the lack of tutorials and indepth technical
> > documentation, is its difficulty in problem identifcation and resolution
> > - even to the hex headed, when something breaks/doesnt work (as
> > expected) the only option is to spend a week (or 2) hacking away at the
> > mighty collection of projects, code, apis and utils (i.e. custom
> > everything) trying to get to grips with whats going on uner the scenes.
> > In my humble opinion, a build system, with its critical posiitoning
> > within the engineering process, has gotta be simple (or at least appear
> > to be without obscuring pertinent details), accessible and above all
> > easy to fix and administer and currently the lack of consistent, user
> > oriented logging and tracing gets in the way of this. Regarding m2s
> > adoption in large scale enterprise dev env projects: yes I need a build
> > fwk that supports/promotes depedency mgmt, standardisation, reporting,
> > network delivery, deployment control, agile SDM techniques and
> > architeral governance but more importantly, i need one that is easy to
> > support, train, administer, adapt, extend and fix. Better messages and
> > message tracing and some proper technical docs will help this i think.
> >
> > Observations:-
> >
> > - Too much noise that is only really meaningful to experts
> > - Unable to distinguish what action has caused a message, part of a
> > wider issue with not being able to associate what is being said, by who,
> > and why (users pov)
> > - No ability to extend message generation/delivery with adapters etc.
> >
> >
> > John Allen.
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
