m2 logging

[John Allen <jo...@hotmail.com>]

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: m2 logging

[Brett Porter <br...@apache.org>]

+1 to this.

Want to add a JIRA to maven-site-plugin for 2.0 to "upgrade velocity
component"?

- Brett

Fabrizio Giustina wrote:
> On 1/11/06, Brett Porter <br...@apache.org> wrote:
>> I think we'd all agree with the sentiment. I think the default needs to
>> be less noisy
> 
> Well, a good start for removing LOTS of useless debug messages while
> generating site or reports could be committing this patch to plexus:
> http://jira.codehaus.org/browse/PLX-180
> I recently reviewed a few m2 plugins, jxr and so on, by reducing the
> log at info level. This plus the plexus-velocity patch should really
> improve the situation...
> 
> 
> fabrizio
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: m2 logging

[Fabrizio Giustina <fg...@apache.org>]

On 1/11/06, Brett Porter <br...@apache.org> wrote:
> I think we'd all agree with the sentiment. I think the default needs to
> be less noisy

Well, a good start for removing LOTS of useless debug messages while
generating site or reports could be committing this patch to plexus:
http://jira.codehaus.org/browse/PLX-180
I recently reviewed a few m2 plugins, jxr and so on, by reducing the
log at info level. This plus the plexus-velocity patch should really
improve the situation...


fabrizio

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: m2 logging

[Jesse McConnell <je...@gmail.com>]

sure thing, might not get to it for a bit...kinda crushed under some other
things but definitely something interesting to look into.

I was just thinking, that perhaps instead of domaining by package, it might
be interesting to try and do it via artifact...I am not sure what kind of
overhead would be involved, but getClass().getResource() works for pulling
out of the jar you are a part of...so we ought to be able to discover the
artifact pretty easily.  Probably not something we want to do every log hit
but some kinda singleton in the plexus logging might be able to manage it...

but by domaining by artifact, you could have the added benefit of logging
context of artifact interaction and by grepping out on a particular artifact
get all of the dealings in that particular artifact.

just a thought

jesse

On 1/11/06, Brett Porter <br...@apache.org> wrote:
>
> Jason van Zyl wrote:
> > 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.
>
> Agreed. So how do we go about this? We can probably match the package
> name to a domain, but I'm not sure how we then rename that and get the
> plexus logger to spit it out.
>
> Jesse, are you interested in investigating?
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom

Re: m2 logging

[Brett Porter <br...@apache.org>]

Jason van Zyl wrote:
> 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.

Agreed. So how do we go about this? We can probably match the package
name to a domain, but I'm not sure how we then rename that and get the
plexus logger to spit it out.

Jesse, are you interested in investigating?

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: m2 logging

[Jason van Zyl <ja...@maven.org>]

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 <br...@apache.org> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 
> 
> --
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: m2 logging

[Jesse McConnell <je...@gmail.com>]

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 <br...@apache.org> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom

Re: m2 logging

[Brett Porter <br...@apache.org>]

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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org