Jesse McConnell wrote:
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..
That would be cool! It would be far simpler for users to track down
specific problems and even if there are intersecting domains involved
you just turn on the logging for the appropriate domain. Very nice idea.
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
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
you are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
