I'm going to work on the 3.1.0 release all this week and then I will clean up
my Logback implementation for comparison and discussion.
On Nov 19, 2012, at 3:38 AM, Olivier Lamy wrote:
> Hi,
> I did the two implementations and it's available for testing:
>
> * https://github.com/olamy/maven-3/t
Hi,
I did the two implementations and it's available for testing:
* https://github.com/olamy/maven-3/tree/logger-mojo-plugin-info (the
mojo logger name is maven.${groupId}.${goal} (see
simplelogger.properties on how to mark a plugin in debug level)
*
https://github.com/olamy/maven-3/commits/logge
Le samedi 17 novembre 2012 08:33:07 Jason van Zyl a écrit :
> On Nov 17, 2012, at 8:01 AM, Hervé BOUTEMY wrote:
> >> Inject the SLF4J logger factory and use that with the underlying
> >> component
> >> descriptor's implementation definition which is the class name.
> >
> > if we change the code,
On Nov 17, 2012, at 8:01 AM, Hervé BOUTEMY wrote:
>>
>> Inject the SLF4J logger factory and use that with the underlying component
>> descriptor's implementation definition which is the class name.
> if we change the code, yes, we can do anything
I mean in the plugin manager in this specific c
Le vendredi 16 novembre 2012 09:45:34 Jason van Zyl a écrit :
> On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
> > On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham
wrote:
> >> I prefer classname based, as it is, by definition, definative.
> >>
> >> If you're concerned about details getting l
after digging into history of refactoring of this info, I found the revision
that added par and ejb3 packagings [1] and corresponding Jira issue [2]
hope this helps
Regards,
Hervé
[1] http://svn.apache.org/viewvc?view=revision&revision=332151
[2] http://jira.codehaus.org/browse/MNG-699
Le ve
To complete the list of Hervé, I was thinking of:
maven [ .$groupId ] .${artifactId} [ [ .${executionId} ] .${goal} ]
Next it would be very nice that if there's an exception during the
process, we could add a line like for instance:
Execute "mvn verify -Lmaven.g.a.e.g=debug" to get extra i
I would not over simplify it.
Application tracing is an implicitly complex or verbose means of generating
application execution trace output.
If you're talking about turning on/off specific mojo tracing it is implicitly
technical and a nitty gritty fine tuning operation.
I think it would be a
Not that I'd ever ever do this, as the performance would be horrid, but:
In the existing logger impl throw and catch an exception and get the *calling*
class from the stack back trace.
Utterly horrid but it is doable. But is works with all existing plugins and
code with out any refactoring (ie
2012/11/16 Stuart McCulloch :
> On 16 Nov 2012, at 14:52, Jason van Zyl wrote:
>
>> And additionally figure what markers might be necessary. So the class name
>> takes care of any hierarchical filtering, and then you get into domain
>> specific filtering. Say you instrumented markers across artif
On Nov 16, 2012, at 10:03 AM, Stuart McCulloch wrote:
> On 16 Nov 2012, at 14:52, Jason van Zyl wrote:
>
>> And additionally figure what markers might be necessary. So the class name
>> takes care of any hierarchical filtering, and then you get into domain
>> specific filtering. Say you instr
On Nov 16, 2012, at 10:25 AM, Olivier Lamy wrote:
> 2012/11/16 Jason van Zyl :
>>
>> On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
>>
>>> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
I prefer classname based, as it is, by definition, definative.
If you're conce
2012/11/16 Jason van Zyl :
>
> On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
>
>> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
>>> I prefer classname based, as it is, by definition, definative.
>>>
>>> If you're concerned about details getting lost, then might I suggest that
>>> yo
On 16 Nov 2012, at 14:52, Jason van Zyl wrote:
> And additionally figure what markers might be necessary. So the class name
> takes care of any hierarchical filtering, and then you get into domain
> specific filtering. Say you instrumented markers across artifact resolution,
> or plugin resolut
And additionally figure what markers might be necessary. So the class name
takes care of any hierarchical filtering, and then you get into domain specific
filtering. Say you instrumented markers across artifact resolution, or plugin
resolution, local repository operations. Many of the markers co
On Nov 16, 2012, at 7:30 AM, Benson Margulies wrote:
> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
>> I prefer classname based, as it is, by definition, definative.
>>
>> If you're concerned about details getting lost, then might I suggest that
>> you route that logging output to a se
On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham wrote:
> I prefer classname based, as it is, by definition, definative.
>
> If you're concerned about details getting lost, then might I suggest that
> you route that logging output to a separate file? trace.log works for me
> (and give a -D to allow u
I prefer classname based, as it is, by definition, definative.
If you're concerned about details getting lost, then might I suggest that
you route that logging output to a separate file? trace.log works for me
(and give a -D to allow users to change that as well).
-Chris
On Fri, Nov 16, 2012 at
+1 for the idea
other complementary ideas:
- groupId is not really useful, plugins's artifactId is in general sufficient
- I'd add goal name
- dot separator, since this is the classical separator in every java logging
implementations (due to the classical class name as logger pattern)
- add prefi
Le jeudi 15 novembre 2012 08:30:11 Jason van Zyl a écrit :
> On Nov 15, 2012, at 8:18 AM, Olivier Lamy wrote:
> > Hi,
> > Currently logger for all mojos is the DefaultPluginManager logger.
> > So it's a bit hard to have filtering per plugin (i.e. only compiler in
> > debug etc..)
> >
> > So I'd l
If you're doing down this way, I would strongly recommend the ability not
only to log specific packages, but to be able to set their logging level as
well.
For example, from WebSphere:
*=info:com.ibm.ws.webcontainer.*=all:com.ibm.ws.wswebcontainer.*=all:com.ibm.wsspi.webcontainer.*=all:HTTPChanne
It looks like Markers[1] are supported in SLF4J and can be used in conjunction
with the class name to gain another axis of control:
[1] http://www.slf4j.org/apidocs/org/slf4j/Marker.html
So this is probably the way it should be done as you don't lose the hierarchy
and if you want an additional
On Thu, Nov 15, 2012 at 11:25 AM, Jason van Zyl wrote:
>
> On Nov 15, 2012, at 11:08 AM, Benson Margulies wrote:
>
>> I can see arguments on both sides of this question of how to pick the
>> logging ID. I'll start with my corner.
>>
>> The convention of having a logger for each class, named after
2012/11/15 Benson Margulies :
> I can see arguments on both sides of this question of how to pick the
> logging ID. I'll start with my corner.
>
> The convention of having a logger for each class, named after the
> class, is just that. A convention. It serves well in many cases.
> However, in my op
On Nov 15, 2012, at 11:08 AM, Benson Margulies wrote:
> I can see arguments on both sides of this question of how to pick the
> logging ID. I'll start with my corner.
>
> The convention of having a logger for each class, named after the
> class, is just that. A convention. It serves well in man
I can see arguments on both sides of this question of how to pick the
logging ID. I'll start with my corner.
The convention of having a logger for each class, named after the
class, is just that. A convention. It serves well in many cases.
However, in my opinion, it threatens to become a sort of c
On Nov 15, 2012, at 8:40 AM, Gary Gregory wrote:
> On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl wrote:
>
>>
>> On Nov 15, 2012, at 8:18 AM, Olivier Lamy wrote:
>>
>>> Hi,
>>> Currently logger for all mojos is the DefaultPluginManager logger.
>>> So it's a bit hard to have filtering per plu
This is simply one of the pros for a logging framework which is domain specific
logging. I'll add it to the list.
On Nov 15, 2012, at 9:00 AM, Mirko Friedenhagen wrote:
> Hello,
>
> not a Maven-developer, but here are my thoughts: I think Jason's
> solution using package.class conventions is m
Hello,
not a Maven-developer, but here are my thoughts: I think Jason's
solution using package.class conventions is more standard. When
someone asks for help, telling them to call (assuming -L would be the
option to set the loggers):
mvn -L org.apache.maven.plugins.release,org.apache.maven.shared
On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl wrote:
>
> On Nov 15, 2012, at 8:18 AM, Olivier Lamy wrote:
>
> > Hi,
> > Currently logger for all mojos is the DefaultPluginManager logger.
> > So it's a bit hard to have filtering per plugin (i.e. only compiler in
> > debug etc..)
> >
> > So I'd l
On Nov 15, 2012, at 8:33 AM, Benson Margulies wrote:
> On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl wrote:
>>
>> On Nov 15, 2012, at 8:18 AM, Olivier Lamy wrote:
>>
>>> Hi,
>>> Currently logger for all mojos is the DefaultPluginManager logger.
>>> So it's a bit hard to have filtering per p
On Thu, Nov 15, 2012 at 8:30 AM, Jason van Zyl wrote:
>
> On Nov 15, 2012, at 8:18 AM, Olivier Lamy wrote:
>
>> Hi,
>> Currently logger for all mojos is the DefaultPluginManager logger.
>> So it's a bit hard to have filtering per plugin (i.e. only compiler in
>> debug etc..)
>>
>> So I'd like to
On Nov 15, 2012, at 8:18 AM, Olivier Lamy wrote:
> Hi,
> Currently logger for all mojos is the DefaultPluginManager logger.
> So it's a bit hard to have filtering per plugin (i.e. only compiler in
> debug etc..)
>
> So I'd like to change that to be able to customize mojo logging.
> My first is
On Thu, Nov 15, 2012 at 8:18 AM, Olivier Lamy wrote:
> Hi,
> Currently logger for all mojos is the DefaultPluginManager logger.
> So it's a bit hard to have filtering per plugin (i.e. only compiler in
> debug etc..)
>
> So I'd like to change that to be able to customize mojo logging.
> My first is
Hi,
Currently logger for all mojos is the DefaultPluginManager logger.
So it's a bit hard to have filtering per plugin (i.e. only compiler in
debug etc..)
So I'd like to change that to be able to customize mojo logging.
My first is idea is mojo with logger name ${groupId}:${artifactId} (ie
org.apa
35 matches
Mail list logo
