You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@tesla.io> on 2012/10/06 21:31:45 UTC
SLF4J integration
The commit for review if anyone wants to take a look is here:
https://github.com/tesla/maven-3/commit/4595e0860243854a7d80db8ebea97205aa4aca65
Ceki added support for logging to a file without massive contortions so I have defaulted the implementation to slf4j-simple which is small and provides the equivalent functionality to the previous setup. It can also be controlled by a simple configuration file. Everything is working but I would like to try and make one small change as currently in debug mode (-X) all the binding information that Sisu knows about is pushed to the console which is very distracting. I think this is more trace level information. Once that is resolved and I write the documentation about how the new logging system works and how the implementations can be swapped I'll dcommit to Apache.
Then I'll add the tests and documentation for the JSR330 work. After that I'll look at the Aether integration. Hope to have this done over the weekend.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is,
the search for a superior moral justification for selfishness.
-- John Kenneth Galbraith
Re: SLF4J integration
Posted by Stephen Connolly <st...@gmail.com>.
On 10 October 2012 14:42, Mark Struberg <st...@yahoo.de> wrote:
> Hi!
>
> Here are a few basic observations about slf4j.
> slf4j really rocks for end user applications, but when it comes to deep
> container core stuff you must take care about classloader clashes much more
> than within an end-user project. We just don't know what a user defined in
> his <plugin> sections…
>
> If we like to use slf4j as maven logging api and export it in the core
> classloader then we might probably face the following problematic spots
>
> 1.) slf4j-api <=1.5 and >=1.6 are not fully binary compatible afaik. Ceki,
> is this correct? Afair there have been a few minor changes between those
> versions. They do not always cause problems but I've seen those in the wild
> already.
>
> 2.) if you use slf4j, then ALL the funnels and logging backends must have
> the very same version number than the slf4j-api. Otherwise you are pretty
> much doomed. Ceki, is this correct as well?
>
> 3.) if we would provide a sfl4j funnel (e.g. log4j-over-slf4j) and a
> plugin brings his own log4j.jar then we will have class path clashes as
> well.
>
> I'm happy if someone tells me the above observations are wrong and I just
> failed to setup the stuff properly. If not, then we still can use slf4j for
> maven BUT we need to isolate it really well via classworlds. And of course
> that would mean that we miss maven logging for those 'isolated' plugins,
> right?
>
>
> I'll first sum up the problems which will occur if the upper assumptions
> are correct.
>
> ad 1.) maven provides slf4j-api-1.6 but a plugin uses slf4j-api-1.5, 1.4,
> etc
> This might cause class cast exceptions ("Cannot cast class Logger to class
> Logger") by having different versions of the slf4j-api classes in different
> ClassLoaders
>
> ad 2.) we provide slf4j-simple-1.6 and user provides slf4j-xxx-1.4. This
> will most probably end up in a big *boom*. And we do not know all slf4j-**
> as any user might easily add his own backend.
>
> ad 3.) We will face class path clashes since a few slf4j funnels are not
> fully binary compatible with the original impls. So funneling is hard to do
> in maven. If others think it is possible, then please point out a way to do
> this properly, thanks!
>
>
> Now for the workaround we could implement:
>
> While discussing this topic with Stephen he had the idea to scan whether a
> plugin uses slf4j by unzipping all plugin dependencies and do some checks.
> E.g. check whether there is a org.slf4j.impl.StaticLoggerBinder.class
>
only unzipping metaphorically, more scan the zip index for
/org/slf4j/impl/StaticLoggerBinder.class
If we see that index in the zip then we know there is an impl => it needs a
fully isolated classloader.
Anyone using funnels in existing plugins will have to be providing an impl
=> the presence of funnels can be inferred by the presence of an impl
That should handle, in as performant a way as I can think of, the issue of
existing plugins which already have slf4j dependencies of a different
version from the one Maven uses.
If we detect this or any slf4j with a version != the version used in
> maven-core, then we must isolate away slf4j provided by the maven core via
> ClassWorlds.
>
What I also suggested is that we add a field to the plugin metadata as a
flag that this plugin needs an isolated slf4j rather than the shared one.
maven-plugin-plugin could add the flag *if not specified* by analyzing the
plugin's bytecode for any use of the slf4j-api method signatures. The flag
would also remove the need to scan the plugin's classpath for slf4j (unless
the user has added/overrided the plugin classpath with <dependency>
overrides... in which case the scanning is back on if we don't know an
isolated classloader is required)
That should allow us to build future backwards compatibility with plugins
being developed in the near future running against Maven 5.0 which uses
slf4j version 3.0 [Note: version numbers are invented, this is not a
commitment to deliver specific versions of dependencies in specific future
versions of Maven]
> I'm happy about any feedback!
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
> > From: Jason van Zyl <ja...@tesla.io>
> > To: Maven Developers List <de...@maven.apache.org>
> > Cc:
> > Sent: Saturday, October 6, 2012 9:31 PM
> > Subject: SLF4J integration
> >
> >T he commit for review if anyone wants to take a look is here:
> >
> >
> https://github.com/tesla/maven-3/commit/4595e0860243854a7d80db8ebea97205aa4aca65
> >
> > Ceki added support for logging to a file without massive contortions so
> I have
> > defaulted the implementation to slf4j-simple which is small and provides
> the
> > equivalent functionality to the previous setup. It can also be
> controlled by a
> > simple configuration file. Everything is working but I would like to try
> and
> > make one small change as currently in debug mode (-X) all the binding
> > information that Sisu knows about is pushed to the console which is very
> > distracting. I think this is more trace level information. Once that is
> resolved
> > and I write the documentation about how the new logging system works
> and how
> > the implementations can be swapped I'll dcommit to Apache.
> >
> > Then I'll add the tests and documentation for the JSR330 work. After that
> > I'll look at the Aether integration. Hope to have this done over the
> > weekend.
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder & CTO, Sonatype
> > Founder, Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> > The modern conservative is engaged in one of man's oldest exercises in
> moral
> > philosophy; that is,
> > the search for a superior moral justification for selfishness.
> >
> > -- John Kenneth Galbraith
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: SLF4J integration
Posted by Jason van Zyl <ja...@tesla.io>.
And I am happy to fix them, but I believe these chains are counter productive as there are hundreds of projects using SLF4J. Many of them here that are integration projects that use SLF4J natively (Camel, ActiveMQ) and we will benefit from their work arounds and solutions. We are not going to benefit from using something no one else does. It is, in fact, true that we wouldn't have any problems using the plexus logger but that's because no one else in the world actually uses it. That's not an overall benefit in my opinion.
With help from others that have integrated SLF4J, Ceki and other people in the SLF4J community we'll resolve the problems.
Mark, Even if the collisions are infrequent and unlikely make the case where it breaks and we'll figure out how to work around it. I think that much more practical than neutering the logging mechanism and not giving users something real to integrate with. The plexus logging system is immature, deficient and not very useful IMO.
On Oct 11, 2012, at 5:27 AM, Stephen Connolly <st...@gmail.com> wrote:
> I really think you need to put a wiki page with all your (I am going to say
> this but for a specific reason) “imagined” problems. That way we can knock
> down the ones that are imagined and leave them dead and focus instead on
> the real ones.
>
> For example the case below is solved with the "is there a
> /org/slf4j/impl/StaticLoggerBinder.class
> entry on the classpath".
>
> Now I agree that the check is not implemented *yet* but what we really need
> to do is identify all the issues and then design the solution that fixes
> all of them in one simple go.
>
> So yes it is a valid issue, but not one we need to keep dragging back up as
> we have already addressed the issue and the solution for that issue.
>
> Please Mark, create a wiki so we can track the valid issues you have and
> the solutions as we find them before you vere into appearing like a
> refusenik ranter.
>
> You are identifying valid issues, but I feel email is ill suited to getting
> those issues identified and resolved.
>
> -Stephen
>
> On 11 October 2012 10:18, Mark Struberg <st...@yahoo.de> wrote:
>
>> Oh I missed one more constellation
>>
>> a plugin could have slf4j-1.5.x + a logging backend we do not know of.
>>
>> I hope such things dont often exist, but in theory it could happen.
>>
>> For all of those cases we need isolation.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Mark Struberg <st...@yahoo.de>
>>> To: Maven Developers List <de...@maven.apache.org>
>>> Cc:
>>> Sent: Thursday, October 11, 2012 10:52 AM
>>> Subject: Re: SLF4J integration
>>>
>>> A the end of the day we could have both actually!
>>>
>>> Most plugins will add both as dependency. Otherwise they would not be
>> able to
>>> log via slf4j.
>>>
>>> But there are also libraries like OpenJPA (via openjpa-maven-plugin)
>> which do
>>> auto detection. They look up what impls are available and decide what to
>> use. In
>>> OpenJPA you can even force the one you like to use via a property in
>>> persistence.xml. So in the real world it's even more complicated.
>>>
>>> I'm not sure how to translate "Das Leben ist kein
>>> Kindergeburtstag" - literally it would be "live is no children
>>> birthday" ;)
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Anders Hammar <an...@hammar.net>
>>>> To: Maven Developers List <de...@maven.apache.org>
>>>> Cc:
>>>> Sent: Thursday, October 11, 2012 10:24 AM
>>>> Subject: Re: SLF4J integration
>>>>
>>>> Just to get this clear in my head:
>>>> When you're talking about "slf4j dependency" in a plugin, are
>>> you
>>>> talking about dependency to slf4j-api or an slf4j impl?
>>>>
>>>> /Anders
>>>>
>>>> On Thu, Oct 11, 2012 at 10:16 AM, ceki <ce...@qos.ch> wrote:
>>>>> On 11.10.2012 08:37, Mark Struberg wrote:
>>>>>
>>>>> Hi Mark,
>>>>>
>>>>>> Hi Ceki, thanks for the reply!
>>>>>
>>>>>
>>>>>>> The method signatures of classes in the org.slf4j package such
>>> as?
>>>>>>> Logger, LoggerFactory, Marker, MDC, etc. are the same since
>>> 2005.?
>>>>>>
>>>>>> No they are not. I did a diff between 1.2 and the latest and it
>>>>>> seems a few trace() methods got added. This is only a minor
>>> problem
>>>>>> but still. This change is perfectly backward compatible, but
>>> it's
>>>> not
>>>>>> forward compatible. If there is any new signature added/changed in
>>> a
>>>>>> newer version which we will not yet use, then we would just crash
>>> if a
>>>>>> plugin uses the newer version. Now this is highly unlikely. But
>>>> I've
>>>>>> seen this with commons logging and I've seen this with the
>>>>>> LocationAwareLoger as you already mentioned below. This is btw
>>> exactly
>>>>>> the reason why we shade in all commons-* stuff to private
>>> packages...
>>>>>
>>>>> Correct. The trace method was added in SLF4J version 1.4 released on
>>>>> May 16th 2007. Interestingly enough, I can't remember a single
>>>>> complaint about missing trace method. About 1% of slf4j-users use
>>>>> versions earlier than 1.4. Among that 1%, even fewer have a
>> dependency
>>>>> requiring the trace method. As an end result, and as far as I can
>>>>> tell, no one complains about the missing trace method in earlier
>> slf4j
>>>>> versions.
>>>>>
>>>>> My point is that there are some imaginary problems that never occur
>> in
>>>>> practice. In practice, the slf4j version some software is compiled
>>>>> with is never a problem assuming it only imports from the org.slf4j
>>>>> package.
>>>>>
>>>>>>> this means that the minor version of the SLF4J binding
>>>>>>> must match that of the slf4j-api. The "maintenance"
>>>>>>> number is unimportant.
>>>>>>
>>>>>
>>>>>> That's perfectly fine that way! Please understand that this is
>>>>>> nothing against slf4j! I just like to avoid that we introduce
>>> build
>>>>>> problems to existing projects. As highlighted in my previous post
>>>>>> there ARE ways to do that (by shielding via ClassWorlds), but this
>>> is
>>>>>> not in place in trunk yet. Also there are zero integration tests
>>> for
>>>>>> it atm!
>>>>>
>>>>> OK.
>>>>>
>>>>>> Maven uses a child-first classloading strategy (with exceptions) -
>>> a
>>>>>> plugin would only see exactly 1 version. Currently (again: there
>>> is
>>>>>> atm no shielding in place yet) if a plugin would would provide
>>> it's
>>>>>> own slf4j-api-1.4.2 then the plugin would get this version of the
>>>>>> Class. And if the plugin would invoke
>>>>>> LoggerFactory.getLogger(this.class()) then what would happen? Most
>>>>>> probably a classcast exception, right? There is a minor chance
>>> that we
>>>>>> do not blow up as there is a complex ClassLoading environment in
>>>>>> place. But we only know after we have some IT in place which do
>>> not
>>>>>> exist yet. All the change got committed without a single IT, thus
>>> my
>>>>>> -1 in the first place.
>>>>>
>>>>>
>>>>> While I agree with the gist of your argument, I still maintain that
>>>>> "slf4j versions" is not the crux of the matter here.
>>> However, as
>>>> you
>>>>> point out, class isolation should be implemented and tested.
>>>>>
>>>>>>
>>>>>>>> 2.) if you use slf4j, then ALL the funnels and logging
>>> backends
>>>> must
>>>>>>>> have the very same version number than the slf4j-api.
>>> Otherwise
>>>> you
>>>>>>>> are pretty much doomed. Ceki, is this correct as well?
>>>>>>>
>>>>>>>
>>>>>>> I would not go as far as "doomed". For example, the
>>>> following
>>>>>>> combination will work fine: slf4j-api-1.7.2.jar,
>>>>>>> sfl4j-simple-1.6.5.jar, log4j-over-slf4j-1.6.2.jar,
>>>>>>> jcl-ocer-slf4j-1.7.1.jar and jul-to-slf4j-1.6.0.jar. In other
>>>> words,
>>>>>>> you can freely mix artifacts in the 1.6.x and 1.7.x families.
>>>>>
>>>>>
>>>>>> But can you freely mix 1.5.x and 1.6.x? or 1.7 and 1.5 or 1.4? No
>>>>>> you cannot as far as I've seen. So we cannot make a general
>>>> assumption
>>>>>> on that! The only safe rule is to not mix slf4j parts with
>>> diverging
>>>>>> major or minor number. Is this correct?
>>>>>
>>>>> Yes, that is correct.
>>>>>
>>>>>
>>>>>>
>>>>>>> Sounds good. I would recommend isolation regardless of the
>>> version
>>>> of
>>>>>>> the discovered slf4j dependency. The plugin author probably
>>> wishes
>>>>>>> logging isolation. Maven should let the plugin have its own
>>>> separate
>>>>>>> logging environment distinct from Maven's own logging.
>>>>>
>>>>>
>>>>>> But that would actually be a big step backwards imo.
>>>>>
>>>>> No, separating maven logging and plugin logging (for the plugins that
>>>>> explicitly set their own slf4j logging environment) is not a step
>>>>> backwards. On the contrary, it preserves existing behavior.
>>>>>
>>>>> In my earlier message, I apparently did not insist enough on the the
>>>>> point that isolation was only required for the minority of plugins
>>>>> which set up their own slf4j-based logging environment. The vast
>>>>> majority of plugins which do not declare an slf4j dependency, would
>>>>> get their slf4j loggers either via injection or via getLogger().
>>>>>
>>>>>> Currently any plugin is forced to 'funnel' the output into
>>> the
>>>>>> logger it obtains via getLogger() itself. This is an instance of
>>>>>> org.apache.maven.plugin.logging.Log and we have it perfectly under
>>> our
>>>>>> own control. It's not a perfectly convenient logging api but
>>> it
>>>> works
>>>>>> and shields us from all implementation details!
>>>>>
>>>>> This has been discussed earlier so I won't respond.
>>>>>
>>>>>> If we would isolate away all the logging of a plugin (because it
>>>>>> contains a diverging slf4j version) then we would loose all this
>>> logs,
>>>>>> right?
>>>>>
>>>>> Of course not. The logs would be available in the logging environment
>>>>> proper to the plugin (declaring its own logging environment),
>>> that's
>>>>> the beauty of this approach.
>>>>>
>>>>>> It is perfectly valid for any plugin to use slf4j right now.
>>>>>
>>>>>
>>>>> Absolutely.
>>>>>
>>>>>> All it needs to do is to funnel it into our own maven logging
>>>>>> api. We could e.g. provide a slf4j-maven-logging backend so users
>>>>>> could use it even more easily.
>>>>>
>>>>>
>>>>> I think that's an understandable mistake but a mistake
>>> nonetheless. We
>>>>> don't want to funnel plugin logging (for a plugin declaring its
>>> own
>>>>> slf4j dependencies) into Maven logging. For one, that's not the
>>>>> *current* behavior as Maven logging and plugin logging (depending on
>>>>> slf4j) are obviously independent. For two, attempts at such
>>> integration
>>>>> quickly become insurmountably complex. Logging integration between
>>>>> Maven and a pluging declaring its own slf4j dependencies is not
>> needed
>>>>> and certainly not worth the effort.
>>>>>
>>>>> If unconvinced, I suggest we study concrete examples.
>>>>>
>>>>> --
>>>>> Ceki
>>>>> 65% of statistics are made up on the spot
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
the course of true love never did run smooth ...
-- Shakespeare
Re: SLF4J integration
Posted by Stephen Connolly <st...@gmail.com>.
I really think you need to put a wiki page with all your (I am going to say
this but for a specific reason) “imagined” problems. That way we can knock
down the ones that are imagined and leave them dead and focus instead on
the real ones.
For example the case below is solved with the "is there a
/org/slf4j/impl/StaticLoggerBinder.class
entry on the classpath".
Now I agree that the check is not implemented *yet* but what we really need
to do is identify all the issues and then design the solution that fixes
all of them in one simple go.
So yes it is a valid issue, but not one we need to keep dragging back up as
we have already addressed the issue and the solution for that issue.
Please Mark, create a wiki so we can track the valid issues you have and
the solutions as we find them before you vere into appearing like a
refusenik ranter.
You are identifying valid issues, but I feel email is ill suited to getting
those issues identified and resolved.
-Stephen
On 11 October 2012 10:18, Mark Struberg <st...@yahoo.de> wrote:
> Oh I missed one more constellation
>
> a plugin could have slf4j-1.5.x + a logging backend we do not know of.
>
> I hope such things dont often exist, but in theory it could happen.
>
> For all of those cases we need isolation.
>
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
> > From: Mark Struberg <st...@yahoo.de>
> > To: Maven Developers List <de...@maven.apache.org>
> > Cc:
> > Sent: Thursday, October 11, 2012 10:52 AM
> > Subject: Re: SLF4J integration
> >
> > A the end of the day we could have both actually!
> >
> > Most plugins will add both as dependency. Otherwise they would not be
> able to
> > log via slf4j.
> >
> > But there are also libraries like OpenJPA (via openjpa-maven-plugin)
> which do
> > auto detection. They look up what impls are available and decide what to
> use. In
> > OpenJPA you can even force the one you like to use via a property in
> > persistence.xml. So in the real world it's even more complicated.
> >
> > I'm not sure how to translate "Das Leben ist kein
> > Kindergeburtstag" - literally it would be "live is no children
> > birthday" ;)
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > ----- Original Message -----
> >> From: Anders Hammar <an...@hammar.net>
> >> To: Maven Developers List <de...@maven.apache.org>
> >> Cc:
> >> Sent: Thursday, October 11, 2012 10:24 AM
> >> Subject: Re: SLF4J integration
> >>
> >> Just to get this clear in my head:
> >> When you're talking about "slf4j dependency" in a plugin, are
> > you
> >> talking about dependency to slf4j-api or an slf4j impl?
> >>
> >> /Anders
> >>
> >> On Thu, Oct 11, 2012 at 10:16 AM, ceki <ce...@qos.ch> wrote:
> >>> On 11.10.2012 08:37, Mark Struberg wrote:
> >>>
> >>> Hi Mark,
> >>>
> >>>> Hi Ceki, thanks for the reply!
> >>>
> >>>
> >>>>> The method signatures of classes in the org.slf4j package such
> > as?
> >>>>> Logger, LoggerFactory, Marker, MDC, etc. are the same since
> > 2005.?
> >>>>
> >>>> No they are not. I did a diff between 1.2 and the latest and it
> >>>> seems a few trace() methods got added. This is only a minor
> > problem
> >>>> but still. This change is perfectly backward compatible, but
> > it's
> >> not
> >>>> forward compatible. If there is any new signature added/changed in
> > a
> >>>> newer version which we will not yet use, then we would just crash
> > if a
> >>>> plugin uses the newer version. Now this is highly unlikely. But
> >> I've
> >>>> seen this with commons logging and I've seen this with the
> >>>> LocationAwareLoger as you already mentioned below. This is btw
> > exactly
> >>>> the reason why we shade in all commons-* stuff to private
> > packages...
> >>>
> >>> Correct. The trace method was added in SLF4J version 1.4 released on
> >>> May 16th 2007. Interestingly enough, I can't remember a single
> >>> complaint about missing trace method. About 1% of slf4j-users use
> >>> versions earlier than 1.4. Among that 1%, even fewer have a
> dependency
> >>> requiring the trace method. As an end result, and as far as I can
> >>> tell, no one complains about the missing trace method in earlier
> slf4j
> >>> versions.
> >>>
> >>> My point is that there are some imaginary problems that never occur
> in
> >>> practice. In practice, the slf4j version some software is compiled
> >>> with is never a problem assuming it only imports from the org.slf4j
> >>> package.
> >>>
> >>>>> this means that the minor version of the SLF4J binding
> >>>>> must match that of the slf4j-api. The "maintenance"
> >>>>> number is unimportant.
> >>>>
> >>>
> >>>> That's perfectly fine that way! Please understand that this is
> >>>> nothing against slf4j! I just like to avoid that we introduce
> > build
> >>>> problems to existing projects. As highlighted in my previous post
> >>>> there ARE ways to do that (by shielding via ClassWorlds), but this
> > is
> >>>> not in place in trunk yet. Also there are zero integration tests
> > for
> >>>> it atm!
> >>>
> >>> OK.
> >>>
> >>>> Maven uses a child-first classloading strategy (with exceptions) -
> > a
> >>>> plugin would only see exactly 1 version. Currently (again: there
> > is
> >>>> atm no shielding in place yet) if a plugin would would provide
> > it's
> >>>> own slf4j-api-1.4.2 then the plugin would get this version of the
> >>>> Class. And if the plugin would invoke
> >>>> LoggerFactory.getLogger(this.class()) then what would happen? Most
> >>>> probably a classcast exception, right? There is a minor chance
> > that we
> >>>> do not blow up as there is a complex ClassLoading environment in
> >>>> place. But we only know after we have some IT in place which do
> > not
> >>>> exist yet. All the change got committed without a single IT, thus
> > my
> >>>> -1 in the first place.
> >>>
> >>>
> >>> While I agree with the gist of your argument, I still maintain that
> >>> "slf4j versions" is not the crux of the matter here.
> > However, as
> >> you
> >>> point out, class isolation should be implemented and tested.
> >>>
> >>>>
> >>>>>> 2.) if you use slf4j, then ALL the funnels and logging
> > backends
> >> must
> >>>>>> have the very same version number than the slf4j-api.
> > Otherwise
> >> you
> >>>>>> are pretty much doomed. Ceki, is this correct as well?
> >>>>>
> >>>>>
> >>>>> I would not go as far as "doomed". For example, the
> >> following
> >>>>> combination will work fine: slf4j-api-1.7.2.jar,
> >>>>> sfl4j-simple-1.6.5.jar, log4j-over-slf4j-1.6.2.jar,
> >>>>> jcl-ocer-slf4j-1.7.1.jar and jul-to-slf4j-1.6.0.jar. In other
> >> words,
> >>>>> you can freely mix artifacts in the 1.6.x and 1.7.x families.
> >>>
> >>>
> >>>> But can you freely mix 1.5.x and 1.6.x? or 1.7 and 1.5 or 1.4? No
> >>>> you cannot as far as I've seen. So we cannot make a general
> >> assumption
> >>>> on that! The only safe rule is to not mix slf4j parts with
> > diverging
> >>>> major or minor number. Is this correct?
> >>>
> >>> Yes, that is correct.
> >>>
> >>>
> >>>>
> >>>>> Sounds good. I would recommend isolation regardless of the
> > version
> >> of
> >>>>> the discovered slf4j dependency. The plugin author probably
> > wishes
> >>>>> logging isolation. Maven should let the plugin have its own
> >> separate
> >>>>> logging environment distinct from Maven's own logging.
> >>>
> >>>
> >>>> But that would actually be a big step backwards imo.
> >>>
> >>> No, separating maven logging and plugin logging (for the plugins that
> >>> explicitly set their own slf4j logging environment) is not a step
> >>> backwards. On the contrary, it preserves existing behavior.
> >>>
> >>> In my earlier message, I apparently did not insist enough on the the
> >>> point that isolation was only required for the minority of plugins
> >>> which set up their own slf4j-based logging environment. The vast
> >>> majority of plugins which do not declare an slf4j dependency, would
> >>> get their slf4j loggers either via injection or via getLogger().
> >>>
> >>>> Currently any plugin is forced to 'funnel' the output into
> > the
> >>>> logger it obtains via getLogger() itself. This is an instance of
> >>>> org.apache.maven.plugin.logging.Log and we have it perfectly under
> > our
> >>>> own control. It's not a perfectly convenient logging api but
> > it
> >> works
> >>>> and shields us from all implementation details!
> >>>
> >>> This has been discussed earlier so I won't respond.
> >>>
> >>>> If we would isolate away all the logging of a plugin (because it
> >>>> contains a diverging slf4j version) then we would loose all this
> > logs,
> >>>> right?
> >>>
> >>> Of course not. The logs would be available in the logging environment
> >>> proper to the plugin (declaring its own logging environment),
> > that's
> >>> the beauty of this approach.
> >>>
> >>>> It is perfectly valid for any plugin to use slf4j right now.
> >>>
> >>>
> >>> Absolutely.
> >>>
> >>>> All it needs to do is to funnel it into our own maven logging
> >>>> api. We could e.g. provide a slf4j-maven-logging backend so users
> >>>> could use it even more easily.
> >>>
> >>>
> >>> I think that's an understandable mistake but a mistake
> > nonetheless. We
> >>> don't want to funnel plugin logging (for a plugin declaring its
> > own
> >>> slf4j dependencies) into Maven logging. For one, that's not the
> >>> *current* behavior as Maven logging and plugin logging (depending on
> >>> slf4j) are obviously independent. For two, attempts at such
> > integration
> >>> quickly become insurmountably complex. Logging integration between
> >>> Maven and a pluging declaring its own slf4j dependencies is not
> needed
> >>> and certainly not worth the effort.
> >>>
> >>> If unconvinced, I suggest we study concrete examples.
> >>>
> >>> --
> >>> Ceki
> >>> 65% of statistics are made up on the spot
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>
> >
> > ---------------------------------------------------------------------
> > 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: SLF4J integration
Posted by Jason van Zyl <ja...@tesla.io>.
Ok, updated. Thanks.
http://tesla.io/maven/logging-with-slf4j.html
On Oct 11, 2012, at 10:34 AM, Anders Hammar <an...@hammar.net> wrote:
> We should clarify that this is for Maven 3.1+, not Maven 3.0.x or Maven 2.
>
> /Anders
>
> On Thu, Oct 11, 2012 at 4:11 PM, Jason van Zyl <ja...@tesla.io> wrote:
>> That's fine, users don't seem to mind.
>>
>> I pretty much have a zero turn around for writing docs using the system I have so that's I'm going to use while iterating. The site plugin supports markdown so I have no problem copying it over when I'm done. You can review when you like.
>>
>> On Oct 11, 2012, at 10:04 AM, Olivier Lamy <ol...@apache.org> wrote:
>>
>>> AFAIK it's a modification and a new feature of Apache Maven code.
>>> So docs MUST be at Apache sources.
>>> Perso I won't review or have a look before you commit that @asf.
>>>
>>>
>>> 2012/10/11 Jason van Zyl <ja...@tesla.io>:
>>>>
>>>> On Oct 11, 2012, at 9:46 AM, "Nord, James" <JN...@nds.com> wrote:
>>>>
>>>>>
>>>>> Hope that clears it up.
>>>>>
>>>>
>>>> Yup, thanks.
>>>>
>>>> http://tesla.io/maven/logging-with-slf4j.html
>>>>
>>>>> Regards,
>>>>>
>>>>> /James
>>>>>
>>>>> ________________________________
>>>>>
>>>>>
>>>>> **************************************************************************************
>>>>> This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.
>>>>>
>>>>> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
>>>>> **************************************************************************************
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder & CTO, Sonatype
>>>> Founder, Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>>
>>>> I never make the mistake of arguing with people for whose opinions I have no respect.
>>>>
>>>> -- Edward Gibbon
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> A man enjoys his work when he understands the whole and when he
>> is responsible for the quality of the whole
>>
>> -- Christopher Alexander, A Pattern Language
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
A language that doesn’t affect the way you think about programming is not worth knowing.
-- Alan Perlis
Re: SLF4J integration
Posted by Anders Hammar <an...@hammar.net>.
We should clarify that this is for Maven 3.1+, not Maven 3.0.x or Maven 2.
/Anders
On Thu, Oct 11, 2012 at 4:11 PM, Jason van Zyl <ja...@tesla.io> wrote:
> That's fine, users don't seem to mind.
>
> I pretty much have a zero turn around for writing docs using the system I have so that's I'm going to use while iterating. The site plugin supports markdown so I have no problem copying it over when I'm done. You can review when you like.
>
> On Oct 11, 2012, at 10:04 AM, Olivier Lamy <ol...@apache.org> wrote:
>
>> AFAIK it's a modification and a new feature of Apache Maven code.
>> So docs MUST be at Apache sources.
>> Perso I won't review or have a look before you commit that @asf.
>>
>>
>> 2012/10/11 Jason van Zyl <ja...@tesla.io>:
>>>
>>> On Oct 11, 2012, at 9:46 AM, "Nord, James" <JN...@nds.com> wrote:
>>>
>>>>
>>>> Hope that clears it up.
>>>>
>>>
>>> Yup, thanks.
>>>
>>> http://tesla.io/maven/logging-with-slf4j.html
>>>
>>>> Regards,
>>>>
>>>> /James
>>>>
>>>> ________________________________
>>>>
>>>>
>>>> **************************************************************************************
>>>> This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.
>>>>
>>>> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
>>>> **************************************************************************************
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>> I never make the mistake of arguing with people for whose opinions I have no respect.
>>>
>>> -- Edward Gibbon
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> A man enjoys his work when he understands the whole and when he
> is responsible for the quality of the whole
>
> -- Christopher Alexander, A Pattern Language
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Jason van Zyl <ja...@tesla.io>.
That's fine, users don't seem to mind.
I pretty much have a zero turn around for writing docs using the system I have so that's I'm going to use while iterating. The site plugin supports markdown so I have no problem copying it over when I'm done. You can review when you like.
On Oct 11, 2012, at 10:04 AM, Olivier Lamy <ol...@apache.org> wrote:
> AFAIK it's a modification and a new feature of Apache Maven code.
> So docs MUST be at Apache sources.
> Perso I won't review or have a look before you commit that @asf.
>
>
> 2012/10/11 Jason van Zyl <ja...@tesla.io>:
>>
>> On Oct 11, 2012, at 9:46 AM, "Nord, James" <JN...@nds.com> wrote:
>>
>>>
>>> Hope that clears it up.
>>>
>>
>> Yup, thanks.
>>
>> http://tesla.io/maven/logging-with-slf4j.html
>>
>>> Regards,
>>>
>>> /James
>>>
>>> ________________________________
>>>
>>>
>>> **************************************************************************************
>>> This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.
>>>
>>> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
>>> **************************************************************************************
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> I never make the mistake of arguing with people for whose opinions I have no respect.
>>
>> -- Edward Gibbon
>>
>>
>>
>>
>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
Re: SLF4J integration
Posted by Olivier Lamy <ol...@apache.org>.
AFAIK it's a modification and a new feature of Apache Maven code.
So docs MUST be at Apache sources.
Perso I won't review or have a look before you commit that @asf.
2012/10/11 Jason van Zyl <ja...@tesla.io>:
>
> On Oct 11, 2012, at 9:46 AM, "Nord, James" <JN...@nds.com> wrote:
>
>>
>> Hope that clears it up.
>>
>
> Yup, thanks.
>
> http://tesla.io/maven/logging-with-slf4j.html
>
>> Regards,
>>
>> /James
>>
>> ________________________________
>>
>>
>> **************************************************************************************
>> This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.
>>
>> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
>> **************************************************************************************
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> I never make the mistake of arguing with people for whose opinions I have no respect.
>
> -- Edward Gibbon
>
>
>
>
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Jason van Zyl <ja...@tesla.io>.
On Oct 11, 2012, at 9:46 AM, "Nord, James" <JN...@nds.com> wrote:
>
> Hope that clears it up.
>
Yup, thanks.
http://tesla.io/maven/logging-with-slf4j.html
> Regards,
>
> /James
>
> ________________________________
>
>
> **************************************************************************************
> This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.
>
> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
> **************************************************************************************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
I never make the mistake of arguing with people for whose opinions I have no respect.
-- Edward Gibbon
RE: SLF4J integration
Posted by "Nord, James" <JN...@nds.com>.
> > The configuration section has a type (I hope)
> >
> > To configure logging with the SLF4J Simple you can edit the properties in the
> ~/m2/conf/logging/simplelogger.properties file.
> >
>
> I actually put it in the distribution as I figured it would not be changed very
> often, I just exposed it in the rare case you wanted to change it.
>
> You think it makes more sense to have it be user configurable?
No - but what you have on the web page is user configurable
Ie you have written <tilde> <slash> <"m2">
Which is /home/myuser/m2/conf... and not /path/to/maven_install/conf
So I am not saying it should be user configurable - but as written it is.
(and if it was user configurable is should be in ".m2" not "m2)
Hope that clears it up.
Regards,
/James
________________________________
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Jason van Zyl <ja...@tesla.io>.
On Oct 11, 2012, at 7:05 AM, "Nord, James" <JN...@nds.com> wrote:
> Hi Jason,
>
> The configuration section has a type (I hope)
>
> To configure logging with the SLF4J Simple you can edit the properties in the ~/m2/conf/logging/simplelogger.properties file.
>
I actually put it in the distribution as I figured it would not be changed very often, I just exposed it in the rare case you wanted to change it.
You think it makes more sense to have it be user configurable?
> That should be ${MAVEN_HOME}/conf... or ~/.m2/...
>
> Other than that - the defaults listed are presumable slf4j defaults and not the defaults from the default configuration (which is confusing to an end user).
>
We changed some of the default configuration for Maven so that the output appeared as close to what they look like now. So they are slightly different.
> /James
>
>> -----Original Message-----
>> From: Jason van Zyl [mailto:jason@tesla.io]
>> Sent: 11 October 2012 11:56
>> To: Maven Developers List
>> Subject: Re: SLF4J integration
>>
>> Here's a first cut at the SLF4J integration documentation[1]. Happy to add
>> anything about potential conflicts, more examples or consider other
>> suggestions. I'll keep editing it until folks are happy and then I'll cut it over to
>> the Maven site:
>>
>> [1]: http://tesla.io/maven/logging-with-slf4j.html
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> People develop abstractions by generalizing from concrete examples.
>> Every attempt to determine the correct abstraction on paper without actually
>> developing a running system is doomed to failure. No one is that smart. A
>> framework is a resuable design, so you develop it by looking at the things it is
>> supposed to be a design of. The more examples you look at, the more general
>> your framework will be.
>>
>> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>>
>>
>>
>>
>
>
> ________________________________
>
>
> **************************************************************************************
> This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.
>
> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
> **************************************************************************************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
A language that doesn’t affect the way you think about programming is not worth knowing.
-- Alan Perlis
RE: SLF4J integration
Posted by "Nord, James" <JN...@nds.com>.
Hi Jason,
The configuration section has a type (I hope)
To configure logging with the SLF4J Simple you can edit the properties in the ~/m2/conf/logging/simplelogger.properties file.
That should be ${MAVEN_HOME}/conf... or ~/.m2/...
Other than that - the defaults listed are presumable slf4j defaults and not the defaults from the default configuration (which is confusing to an end user).
/James
> -----Original Message-----
> From: Jason van Zyl [mailto:jason@tesla.io]
> Sent: 11 October 2012 11:56
> To: Maven Developers List
> Subject: Re: SLF4J integration
>
> Here's a first cut at the SLF4J integration documentation[1]. Happy to add
> anything about potential conflicts, more examples or consider other
> suggestions. I'll keep editing it until folks are happy and then I'll cut it over to
> the Maven site:
>
> [1]: http://tesla.io/maven/logging-with-slf4j.html
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> People develop abstractions by generalizing from concrete examples.
> Every attempt to determine the correct abstraction on paper without actually
> developing a running system is doomed to failure. No one is that smart. A
> framework is a resuable design, so you develop it by looking at the things it is
> supposed to be a design of. The more examples you look at, the more general
> your framework will be.
>
> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>
>
>
>
________________________________
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Jason van Zyl <ja...@tesla.io>.
Here's a first cut at the SLF4J integration documentation[1]. Happy to add anything about potential conflicts, more examples or consider other suggestions. I'll keep editing it until folks are happy and then I'll cut it over to the Maven site:
[1]: http://tesla.io/maven/logging-with-slf4j.html
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
Re: SLF4J integration
Posted by Jason van Zyl <ja...@tesla.io>.
On Oct 11, 2012, at 6:43 AM, Mark Struberg <st...@yahoo.de> wrote:
> ceki, really, this is perfect example why no container uses commons-logging anymore.
> Do you like to repeat these errors?
>
>
> I reiterate: there is a workaround by isolating this in ClassWorlds. It is not yet there, but ff we like to use slf4j then we will need to implement that.
>
I will agree with Ceki and Stephen that these may happen, and we can fix it in the field if it does but I believe it will be rare and I don't like fixing problems that aren't really problems yet. In the very worst case here to prevent problems to tool being integrated can fork. But really if you want to construct those cases do so and we'll take a look at how we approach dealing with it. As Ceki said, and we should all defer to his experience with logging, it's impossible to deal with all scenarios well but that shouldn't stop us from trying to make logging better for the vast majority of cases.
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: ceki <ce...@qos.ch>
>> To: Maven Developers List <de...@maven.apache.org>
>> Cc:
>> Sent: Thursday, October 11, 2012 12:25 PM
>> Subject: Re: SLF4J integration
>>
>> On 11.10.2012 11:18, Mark Struberg wrote:
>>> Oh I missed one more constellation
>>>
>>> a plugin could have slf4j-1.5.x + a logging backend we do not know of.
>>>
>>> I hope such things dont often exist, but in theory it could happen.
>>>
>>> For all of those cases we need isolation.
>>
>> A few months before creating the SLF4J project, I had a lengthy
>> conversation on the commons-dev mailing list about logging scenarios.
>> Richard Sitze (from IBM) offered a number of complex scenarios, and
>> that's when the penny finally dropped for me [1]. It is a waste of time
>> catering for all imaginable logging scenarios. The space of possible
>> logging scenarios is truly vast. However, only a very limited number of
>> these scenarios occur in practice. It makes more sense to concentrate
>> on the common scenarios to ensure that they are well supported.
>>
>> More concretely, I propose that we find one or two examples of plugins
>> declaring an slf4j dependency and test these plugins with the upcoming
>> version of maven (the one using slf4j).
>>
>> [1] http://marc.info/?t=110780972600001&r=1&w=2
>>
>> --
>> Ceki
>> 65% of statistics are made up on the spot
>>
>> ---------------------------------------------------------------------
>> 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
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
Re: SLF4J integration
Posted by Mark Struberg <st...@yahoo.de>.
I have no figures. But please don't forget that not all plugins are public. There are a lot of custom plugins used in companies.
I know that e.g. the openjpa-maven-plugin supports slf4j if you configure it in your persistence.xml.
LieGrue,
strub
----- Original Message -----
> From: ceki <ce...@qos.ch>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Thursday, October 11, 2012 1:26 PM
> Subject: Re: SLF4J integration
>
> On 11.10.2012 12:43, Mark Struberg wrote:
>
>> ceki, really, this is perfect example why no container uses
>> commons-logging anymore. Do you like to repeat these errors?
>>
>> I reiterate: there is a workaround by isolating this in
>> ClassWorlds. It is not yet there, but ff we like to use slf4j then we
>> will need to implement that.
>
> How about looking at actual plugins? Do you have examples of plugins declaring a
> dependency on slf4j? Anyone else?
>
> -- Ceki
> 65% of statistics are made up on the spot
>
> ---------------------------------------------------------------------
> 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: SLF4J integration
Posted by Jason van Zyl <ja...@tesla.io>.
On Oct 11, 2012, at 4:29 PM, Mark Struberg <st...@yahoo.de> wrote:
>
> But happily the LocationAwareLogger method only gets invoked if the configured logging backend is a LocationAwareLogger. And slf4j-simple isn't such a thing, right? If a user switches to logback and a more advanced logging config then you are back to maven blurp.
>
We've not seen this integrating SLF4J and Logback with m2e which is probably the most widely distributed integration of Maven.
> Now the workaround. It works if you just add a <dependency> with a newer version to the plugin configuration. Thats for sure not a show stopper. We just need to document it in a FAQ.
>
> I gonna refine the IT and check it in in the next days.
>
>
> LieGrue,
> strub
>
>
> ----- Original Message -----
>> From: Mark Struberg <st...@yahoo.de>
>> To: Maven Developers List <de...@maven.apache.org>
>> Cc:
>> Sent: Thursday, October 11, 2012 5:56 PM
>> Subject: Re: SLF4J integration
>>
>> Benson, I already pointed to a few plugins which are broken with trunk. And
>> OpenJPA is not a highly out of the world usage scenario!
>>
>> Please tell me what exactly you think you would gain from exposing slf4j to
>> plugins and then we can discuss about if this is possibly without breaking
>> stuff.
>>
>> Again: this is not a discussion about different design decisions - we are
>> talking about bombing out with Exceptions for approx 5% of all builds!
>>
>>
>> It might be _perfectly_ fine to use slf4j internally. But by exposing it to the
>> plugin classpath we do gain almost nothing and get into class hell. We could
>> just remove it from the Classworld core realm and then we would be fine as well.
>>
>>
>> Btw, instead of switching hardcoded from log4j to hardcoded slf4j we again do
>> not gain much. I'd expect a pluggable/configurable mechanism here.
>>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>>> From: Benson Margulies <bi...@gmail.com>
>>> To: Maven Developers List <de...@maven.apache.org>; Mark Struberg
>> <st...@yahoo.de>
>>> Cc:
>>> Sent: Thursday, October 11, 2012 5:16 PM
>>> Subject: Re: SLF4J integration
>>>
>>> On Thu, Oct 11, 2012 at 11:08 AM, Mark Struberg <st...@yahoo.de>
>> wrote:
>>>> Benson, it's a pity that this happened to you, and I blame it on
>> some
>>> plugin bug which should get fixed. Forcing a maven upgrade just because
>>> something is buggy is not a serious option. It's ok for well intended
>> new
>>> features, but not if it's just a matter of a bug.
>>>>
>>>> And knowingly breaking tons of existing builds is not an option
>> neither
>>> imo. And this is what Jasons commit did. And it was not even a commented
>> feature
>>> commit but a 'side effect' of the (btw broken as well afaik)
>> @Inject
>>> enabling commit. This would be a nightmare for thousands of company users
>> which
>>> are not allowed to update their build infrastructure that easily.
>>>
>>> 'tons of existing builds'? Mark, you continue to claim that slf4j
>>> dependencies are think on the ground, but offer no evidence. And it's
>>> not a 'break', in my opinion, to say that a X.Y release is not
>>> completely backwards compatible. No one is forced to use the new
>>> version. They can transition when its convenient.
>>>
>>> Having flexibility to change the logging back end is a positive value
>>> to the overall maven platform, and i'm prepared to go along with this
>>> plan, which accepts some possible inconvenience to some adopters as
>>> the price of it. If there were lots of other people agreeing with you,
>>> I'd be OK with looking for a stronger isolation technique to insulate
>>> the maven core's decision about how to route log messages from the
>>> decision of any one plugin. Right now, it appears (and perhaps I'm
>>> misreading the sense of the discussion) that you're the only person
>>> unhappy with this plan.
>>>
>>> Also, could someone please clarify for me whether slf4j changes have
>>> been committed to the trunk, or merely to a branch? I'm afraid that
>>> I've got two topics mixed up in my head.
>>>
>>> As for my problem with the buildnumber build, until someone explains
>>> it, we know nothing. I put it out there as evidence that something,
>>> somewhere, in the build of that touched sl4fj long before JvZ did
>>> anything discussed here, and I thought that perhaps someone might be
>>> interested in working out "what".
>>>
>>>
>>>
>>>>
>>>>
>>>> To short version: the current trunk is broken and there is no benefit
>> by
>>> exposing slf4j in the near future.
>>>>
>>>> The slightly longer version:
>>>>
>>>> Any builds with a plugin dependency on slf4j < 1.6 is broken with
>> the
>>> current trunk and will blow up. Even Ceki admitted that.
>>>>
>>>> There is a possible fix by isolating all plugins which provide slf4j
>>> logging themself. But then those plugins will NOT use mavens slf4j logging
>>> anymore but their own. So for all those plugins the slf4j provided by maven
>> is
>>> useless.
>>>>
>>>>
>>>> And if a plugin uses slf4j for logging and does NOT provide an own
>> slf4j
>>> backend, then it will be broken with _all_ already existing maven versions.
>> And
>>> there is not even a migration path between those 2 modes.
>>>>
>>>> If we expose the slf4j api now, then you would need to wait
>> approximately 2
>>> years before any plugins can start using it. 2 years is a long time in the
>>> computer industry...
>>>>
>>>>
>>>> Again, this has _nothing_ to do with slf4j! I would also be -1 for
>> exposing
>>> commons-logging, log4j or any other existing logging framework which could
>> exist
>>>>
>>>> in user plugins! They just introduce classloader problems alltogether.
>>>>
>>>>
>>>> The only framework which might be ok would java.util.logging. Yea jul
>> sucks
>>> as hell and if used badly it creates permgen issues and other side effects.
>> But
>>> at least it doesnt create class clashes.
>>>>
>>>> The best we could do is to provide a maven.plugin.Logger backend for
>> slf4j.
>>>>
>>>>
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: Benson Margulies <bi...@gmail.com>
>>>>> To: Maven Developers List <de...@maven.apache.org>; Mark
>> Struberg
>>> <st...@yahoo.de>
>>>>> Cc:
>>>>> Sent: Thursday, October 11, 2012 2:14 PM
>>>>> Subject: Re: SLF4J integration
>>>>>
>>>>> 1. I have an example of something. I don't quite know what.
>>>>>
>>>>> I went to release the buildnumber-maven-plugin from the mojo
>> project,
>>>>> using 2.2.1. I got a murky error about slf4j, followed by a
>> failure to
>>>>> find a 'dav' transport.
>>>>>
>>>>> So I patched in wagon-dav, and I now the only problem was the
>> slf4j
>>>>> complaint. So I want with 3.0.4, and all was well.
>>>>>
>>>>> 2. Let's keep this in perspective: worst case: some plugin
>>> doesn't
>>>>> work with 3.1 until adjusted. Unless the claim is that there is no
>>>>> simple or practical adjustment fot some reasonable case, this
>>> doesn't
>>>>> bother me.
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
I never make the mistake of arguing with people for whose opinions I have no respect.
-- Edward Gibbon
Re: SLF4J integration
Posted by Mark Struberg <st...@yahoo.de>.
Oki, back from my IT testing orgy with slf4j.
I managed to break the build, but the good news: it was actually much harder than I thought. Plus I found a pretty easy workaround!
First an analysis from the classloader perspective. Whatever you configure as slf4j-api version in any plugin will not be used because the slf4j-api from the core-realm will always be taken. Also the org.slf4j.impl.StaticLoggerBinder will only be picked up from the core realm as far as I've seen. Thus we can rule out any problems between slf4j-api and the logger backend. Of course this means that any configured logging backends of your plugin will not be used if I observed this correctly. Another minor issue is that we currently have slf4j-nop in our trunk which just swallows all slf4j logs at all. We should use slf4j-simple instead.
Now for the client side: using a jcl-to-slf4j jar 1.5.8
This gets perfectly picked up by the plugin classloader and will be used. As already reported by Ceki the LocationAwareLogger is the most problematic API. If any funnel uses a LocationAwareLogger then maven blows up.
But happily the LocationAwareLogger method only gets invoked if the configured logging backend is a LocationAwareLogger. And slf4j-simple isn't such a thing, right? If a user switches to logback and a more advanced logging config then you are back to maven blurp.
Now the workaround. It works if you just add a <dependency> with a newer version to the plugin configuration. Thats for sure not a show stopper. We just need to document it in a FAQ.
I gonna refine the IT and check it in in the next days.
LieGrue,
strub
----- Original Message -----
> From: Mark Struberg <st...@yahoo.de>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Thursday, October 11, 2012 5:56 PM
> Subject: Re: SLF4J integration
>
> Benson, I already pointed to a few plugins which are broken with trunk. And
> OpenJPA is not a highly out of the world usage scenario!
>
> Please tell me what exactly you think you would gain from exposing slf4j to
> plugins and then we can discuss about if this is possibly without breaking
> stuff.
>
> Again: this is not a discussion about different design decisions - we are
> talking about bombing out with Exceptions for approx 5% of all builds!
>
>
> It might be _perfectly_ fine to use slf4j internally. But by exposing it to the
> plugin classpath we do gain almost nothing and get into class hell. We could
> just remove it from the Classworld core realm and then we would be fine as well.
>
>
> Btw, instead of switching hardcoded from log4j to hardcoded slf4j we again do
> not gain much. I'd expect a pluggable/configurable mechanism here.
>
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Benson Margulies <bi...@gmail.com>
>> To: Maven Developers List <de...@maven.apache.org>; Mark Struberg
> <st...@yahoo.de>
>> Cc:
>> Sent: Thursday, October 11, 2012 5:16 PM
>> Subject: Re: SLF4J integration
>>
>> On Thu, Oct 11, 2012 at 11:08 AM, Mark Struberg <st...@yahoo.de>
> wrote:
>>> Benson, it's a pity that this happened to you, and I blame it on
> some
>> plugin bug which should get fixed. Forcing a maven upgrade just because
>> something is buggy is not a serious option. It's ok for well intended
> new
>> features, but not if it's just a matter of a bug.
>>>
>>> And knowingly breaking tons of existing builds is not an option
> neither
>> imo. And this is what Jasons commit did. And it was not even a commented
> feature
>> commit but a 'side effect' of the (btw broken as well afaik)
> @Inject
>> enabling commit. This would be a nightmare for thousands of company users
> which
>> are not allowed to update their build infrastructure that easily.
>>
>> 'tons of existing builds'? Mark, you continue to claim that slf4j
>> dependencies are think on the ground, but offer no evidence. And it's
>> not a 'break', in my opinion, to say that a X.Y release is not
>> completely backwards compatible. No one is forced to use the new
>> version. They can transition when its convenient.
>>
>> Having flexibility to change the logging back end is a positive value
>> to the overall maven platform, and i'm prepared to go along with this
>> plan, which accepts some possible inconvenience to some adopters as
>> the price of it. If there were lots of other people agreeing with you,
>> I'd be OK with looking for a stronger isolation technique to insulate
>> the maven core's decision about how to route log messages from the
>> decision of any one plugin. Right now, it appears (and perhaps I'm
>> misreading the sense of the discussion) that you're the only person
>> unhappy with this plan.
>>
>> Also, could someone please clarify for me whether slf4j changes have
>> been committed to the trunk, or merely to a branch? I'm afraid that
>> I've got two topics mixed up in my head.
>>
>> As for my problem with the buildnumber build, until someone explains
>> it, we know nothing. I put it out there as evidence that something,
>> somewhere, in the build of that touched sl4fj long before JvZ did
>> anything discussed here, and I thought that perhaps someone might be
>> interested in working out "what".
>>
>>
>>
>>>
>>>
>>> To short version: the current trunk is broken and there is no benefit
> by
>> exposing slf4j in the near future.
>>>
>>> The slightly longer version:
>>>
>>> Any builds with a plugin dependency on slf4j < 1.6 is broken with
> the
>> current trunk and will blow up. Even Ceki admitted that.
>>>
>>> There is a possible fix by isolating all plugins which provide slf4j
>> logging themself. But then those plugins will NOT use mavens slf4j logging
>> anymore but their own. So for all those plugins the slf4j provided by maven
> is
>> useless.
>>>
>>>
>>> And if a plugin uses slf4j for logging and does NOT provide an own
> slf4j
>> backend, then it will be broken with _all_ already existing maven versions.
> And
>> there is not even a migration path between those 2 modes.
>>>
>>> If we expose the slf4j api now, then you would need to wait
> approximately 2
>> years before any plugins can start using it. 2 years is a long time in the
>> computer industry...
>>>
>>>
>>> Again, this has _nothing_ to do with slf4j! I would also be -1 for
> exposing
>> commons-logging, log4j or any other existing logging framework which could
> exist
>>>
>>> in user plugins! They just introduce classloader problems alltogether.
>>>
>>>
>>> The only framework which might be ok would java.util.logging. Yea jul
> sucks
>> as hell and if used badly it creates permgen issues and other side effects.
> But
>> at least it doesnt create class clashes.
>>>
>>> The best we could do is to provide a maven.plugin.Logger backend for
> slf4j.
>>>
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Benson Margulies <bi...@gmail.com>
>>>> To: Maven Developers List <de...@maven.apache.org>; Mark
> Struberg
>> <st...@yahoo.de>
>>>> Cc:
>>>> Sent: Thursday, October 11, 2012 2:14 PM
>>>> Subject: Re: SLF4J integration
>>>>
>>>> 1. I have an example of something. I don't quite know what.
>>>>
>>>> I went to release the buildnumber-maven-plugin from the mojo
> project,
>>>> using 2.2.1. I got a murky error about slf4j, followed by a
> failure to
>>>> find a 'dav' transport.
>>>>
>>>> So I patched in wagon-dav, and I now the only problem was the
> slf4j
>>>> complaint. So I want with 3.0.4, and all was well.
>>>>
>>>> 2. Let's keep this in perspective: worst case: some plugin
>> doesn't
>>>> work with 3.1 until adjusted. Unless the claim is that there is no
>>>> simple or practical adjustment fot some reasonable case, this
>> doesn't
>>>> bother me.
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> 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
>>>
>>
>
> ---------------------------------------------------------------------
> 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: SLF4J integration
Posted by Mark Struberg <st...@yahoo.de>.
Benson, I already pointed to a few plugins which are broken with trunk. And OpenJPA is not a highly out of the world usage scenario!
Please tell me what exactly you think you would gain from exposing slf4j to plugins and then we can discuss about if this is possibly without breaking stuff.
Again: this is not a discussion about different design decisions - we are talking about bombing out with Exceptions for approx 5% of all builds!
It might be _perfectly_ fine to use slf4j internally. But by exposing it to the plugin classpath we do gain almost nothing and get into class hell. We could just remove it from the Classworld core realm and then we would be fine as well.
Btw, instead of switching hardcoded from log4j to hardcoded slf4j we again do not gain much. I'd expect a pluggable/configurable mechanism here.
LieGrue,
strub
----- Original Message -----
> From: Benson Margulies <bi...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>; Mark Struberg <st...@yahoo.de>
> Cc:
> Sent: Thursday, October 11, 2012 5:16 PM
> Subject: Re: SLF4J integration
>
> On Thu, Oct 11, 2012 at 11:08 AM, Mark Struberg <st...@yahoo.de> wrote:
>> Benson, it's a pity that this happened to you, and I blame it on some
> plugin bug which should get fixed. Forcing a maven upgrade just because
> something is buggy is not a serious option. It's ok for well intended new
> features, but not if it's just a matter of a bug.
>>
>> And knowingly breaking tons of existing builds is not an option neither
> imo. And this is what Jasons commit did. And it was not even a commented feature
> commit but a 'side effect' of the (btw broken as well afaik) @Inject
> enabling commit. This would be a nightmare for thousands of company users which
> are not allowed to update their build infrastructure that easily.
>
> 'tons of existing builds'? Mark, you continue to claim that slf4j
> dependencies are think on the ground, but offer no evidence. And it's
> not a 'break', in my opinion, to say that a X.Y release is not
> completely backwards compatible. No one is forced to use the new
> version. They can transition when its convenient.
>
> Having flexibility to change the logging back end is a positive value
> to the overall maven platform, and i'm prepared to go along with this
> plan, which accepts some possible inconvenience to some adopters as
> the price of it. If there were lots of other people agreeing with you,
> I'd be OK with looking for a stronger isolation technique to insulate
> the maven core's decision about how to route log messages from the
> decision of any one plugin. Right now, it appears (and perhaps I'm
> misreading the sense of the discussion) that you're the only person
> unhappy with this plan.
>
> Also, could someone please clarify for me whether slf4j changes have
> been committed to the trunk, or merely to a branch? I'm afraid that
> I've got two topics mixed up in my head.
>
> As for my problem with the buildnumber build, until someone explains
> it, we know nothing. I put it out there as evidence that something,
> somewhere, in the build of that touched sl4fj long before JvZ did
> anything discussed here, and I thought that perhaps someone might be
> interested in working out "what".
>
>
>
>>
>>
>> To short version: the current trunk is broken and there is no benefit by
> exposing slf4j in the near future.
>>
>> The slightly longer version:
>>
>> Any builds with a plugin dependency on slf4j < 1.6 is broken with the
> current trunk and will blow up. Even Ceki admitted that.
>>
>> There is a possible fix by isolating all plugins which provide slf4j
> logging themself. But then those plugins will NOT use mavens slf4j logging
> anymore but their own. So for all those plugins the slf4j provided by maven is
> useless.
>>
>>
>> And if a plugin uses slf4j for logging and does NOT provide an own slf4j
> backend, then it will be broken with _all_ already existing maven versions. And
> there is not even a migration path between those 2 modes.
>>
>> If we expose the slf4j api now, then you would need to wait approximately 2
> years before any plugins can start using it. 2 years is a long time in the
> computer industry...
>>
>>
>> Again, this has _nothing_ to do with slf4j! I would also be -1 for exposing
> commons-logging, log4j or any other existing logging framework which could exist
>>
>> in user plugins! They just introduce classloader problems alltogether.
>>
>>
>> The only framework which might be ok would java.util.logging. Yea jul sucks
> as hell and if used badly it creates permgen issues and other side effects. But
> at least it doesnt create class clashes.
>>
>> The best we could do is to provide a maven.plugin.Logger backend for slf4j.
>>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Benson Margulies <bi...@gmail.com>
>>> To: Maven Developers List <de...@maven.apache.org>; Mark Struberg
> <st...@yahoo.de>
>>> Cc:
>>> Sent: Thursday, October 11, 2012 2:14 PM
>>> Subject: Re: SLF4J integration
>>>
>>> 1. I have an example of something. I don't quite know what.
>>>
>>> I went to release the buildnumber-maven-plugin from the mojo project,
>>> using 2.2.1. I got a murky error about slf4j, followed by a failure to
>>> find a 'dav' transport.
>>>
>>> So I patched in wagon-dav, and I now the only problem was the slf4j
>>> complaint. So I want with 3.0.4, and all was well.
>>>
>>> 2. Let's keep this in perspective: worst case: some plugin
> doesn't
>>> work with 3.1 until adjusted. Unless the claim is that there is no
>>> simple or practical adjustment fot some reasonable case, this
> doesn't
>>> bother me.
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Merged or separated logs WAS: SLF4J integration
Posted by Jason van Zyl <ja...@tesla.io>.
I believe we will be able to have more controlled "veins" of logging, or domain specific logging, once SLF4J is in place. For example if I'm interested only in plugin execution, or artifact resolution we will be able to do that.
On Oct 12, 2012, at 9:22 AM, Anders Hammar <an...@hammar.net> wrote:
>>> If all logging from the embedded framework gets directed to the Maven
>>> output console, it could get messy. I'm thinking something like how
>>> the surefire plugin works where the user is directed to the surefire
>>> reports for further problem info (stacktraces etc.)
>> those would be the cases where the plugin would indicate that it wants
>> isolated logging.
>
> Maybe I (as an end Maven user) don't want the plugin developer to
> decide this. It might be the decision for the build (or even the
> specific end user).
>
> Here's a use case:
> I very much dislike verbose output to the Maven console. Some people
> tend to add LOTS of debug logging in their unit tests, which makes it
> hard to read the console for me if I'm not the familiar with the
> build. For example, there could be exceptions, stack traces, etc.
> which are due to tests testing cases where there should be exceptions.
> So everything is good, but I see "ERROR", "FATAL", etc in the console
> and get worried. I rather do debugging if there's an reported error,
> but some developers rather find the problem through outputs.
>
> Should we decide in m-surefire-p if logging from JUnit tests should be
> in the console or not? I think not. It should be for the end user to
> decide (I guess that could be done in the Maven core logging config
> then) or for the specific build project (thus, checked into scm). Not
> sure how the latter should be handled though.
>
> Maybe I'm just making this too complicated. I think we need to keep
> this simple. And then refine it as we go.
>
> /Anders
>
>>
>>
>>>
>>> Well, just some thoughts.
>>>
>>> /Anders
>>>
>>>>
>>>>
>>>> --
>>>> Ceki
>>>> 65% of statistics are made up on the spot
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
Re: Merged or separated logs WAS: SLF4J integration
Posted by Anders Hammar <an...@hammar.net>.
>> If all logging from the embedded framework gets directed to the Maven
>> output console, it could get messy. I'm thinking something like how
>> the surefire plugin works where the user is directed to the surefire
>> reports for further problem info (stacktraces etc.)
> those would be the cases where the plugin would indicate that it wants
> isolated logging.
Maybe I (as an end Maven user) don't want the plugin developer to
decide this. It might be the decision for the build (or even the
specific end user).
Here's a use case:
I very much dislike verbose output to the Maven console. Some people
tend to add LOTS of debug logging in their unit tests, which makes it
hard to read the console for me if I'm not the familiar with the
build. For example, there could be exceptions, stack traces, etc.
which are due to tests testing cases where there should be exceptions.
So everything is good, but I see "ERROR", "FATAL", etc in the console
and get worried. I rather do debugging if there's an reported error,
but some developers rather find the problem through outputs.
Should we decide in m-surefire-p if logging from JUnit tests should be
in the console or not? I think not. It should be for the end user to
decide (I guess that could be done in the Maven core logging config
then) or for the specific build project (thus, checked into scm). Not
sure how the latter should be handled though.
Maybe I'm just making this too complicated. I think we need to keep
this simple. And then refine it as we go.
/Anders
>
>
>>
>> Well, just some thoughts.
>>
>> /Anders
>>
>> >
>> >
>> > --
>> > Ceki
>> > 65% of statistics are made up on the spot
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Merged or separated logs WAS: SLF4J integration
Posted by Stephen Connolly <st...@gmail.com>.
On 12 October 2012 13:12, Anders Hammar <an...@hammar.net> wrote:
> > In the context of Maven, is there any added value in pluging having a
> > separated logging environment? If there is no added value, then merged
> > logging is the way to go.
>
Going separate makes it very difficult for the end user to figure out how
they are supposed to configure the logging levels.
Consider the case of jetty:run.
I want to turn down a specific logger in the servlet as it generates a lot
of noize, and another one needs turning up to DEBUG to catch the events of
interest.
If we don't have merged logging I have no clue where to start. With merged
logging it is the same place I configure anything for Maven and logging...
a usability win from my PoV
> Could one possible case be a plugin which embeds some "framework"
> which uses slf4j to log to it's own log file(s)? And in this case you
> might want to keep the original framework's default logging behavior.
> Don't know of such case in reality, but it popped to my mind thinking
> about how the Cargo plugin works. It embeds an app server or web
> container and that container could be using slf4j already. Currently
> Cargo only supports Jetty in embedded mode though, and I don't know if
> Jetty uses slf4j or some other logging framework/API.
>
IIRC jetty will use slf4j if present, otherwise it does its own thing.
So if the plugin classloader exposes the slf4j-api then that's where the
jetty logs will go.
Mind you, for jetty as it currently stands you're still getting the logs
routed to the console by default so sending them via the shared slf4j just
means that the logs will be consistently formatted... which is a win from
my PoV.
I think the key thing to do is allow plugins to declare whether they want
shared logging or not, and then instantiate the classloader
correspondingly. We can do inference based on the presence of a slf4j
implementation class as a help, or we can do the simpler thing which is
assume they want it shared and let people fix by exception.
> If all logging from the embedded framework gets directed to the Maven
> output console, it could get messy. I'm thinking something like how
> the surefire plugin works where the user is directed to the surefire
> reports for further problem info (stacktraces etc.)
>
those would be the cases where the plugin would indicate that it wants
isolated logging.
>
> Well, just some thoughts.
>
> /Anders
>
> >
> >
> > --
> > Ceki
> > 65% of statistics are made up on the spot
> >
> > ---------------------------------------------------------------------
> > 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: Merged or separated logs WAS: SLF4J integration
Posted by Anders Hammar <an...@hammar.net>.
> In the case of Cargo does it fork by default and there the logging is all self-contained by virtue of running in its own VM?
To be honest I don't know. I think it doesn't fork, but I could be
wrong. But it doesn't really matter, Cargo was just one example.
But after having spent some more time thinking about it I recall that
I in the beginning of my Cargo days I actually was confused about
where the container logging went. So it might actually be better to
route to the console by default and give the user the possibility to
configure the logging levels.
In any case, I think that would be a good place to start and then add
more advanced possibilities if needed. Keep it simple.
/Anders
>
> On Oct 12, 2012, at 8:12 AM, Anders Hammar <an...@hammar.net> wrote:
>
>>> In the context of Maven, is there any added value in pluging having a
>>> separated logging environment? If there is no added value, then merged
>>> logging is the way to go.
>>
>> Could one possible case be a plugin which embeds some "framework"
>> which uses slf4j to log to it's own log file(s)? And in this case you
>> might want to keep the original framework's default logging behavior.
>> Don't know of such case in reality, but it popped to my mind thinking
>> about how the Cargo plugin works. It embeds an app server or web
>> container and that container could be using slf4j already. Currently
>> Cargo only supports Jetty in embedded mode though, and I don't know if
>> Jetty uses slf4j or some other logging framework/API.
>>
>> If all logging from the embedded framework gets directed to the Maven
>> output console, it could get messy. I'm thinking something like how
>> the surefire plugin works where the user is directed to the surefire
>> reports for further problem info (stacktraces etc.)
>>
>> Well, just some thoughts.
>>
>> /Anders
>>
>>>
>>>
>>> --
>>> Ceki
>>> 65% of statistics are made up on the spot
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will come
> and sit softly on your shoulder ...
>
> -- Thoreau
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Merged or separated logs WAS: SLF4J integration
Posted by Jason van Zyl <ja...@tesla.io>.
In the case of Cargo does it fork by default and there the logging is all self-contained by virtue of running in its own VM?
On Oct 12, 2012, at 8:12 AM, Anders Hammar <an...@hammar.net> wrote:
>> In the context of Maven, is there any added value in pluging having a
>> separated logging environment? If there is no added value, then merged
>> logging is the way to go.
>
> Could one possible case be a plugin which embeds some "framework"
> which uses slf4j to log to it's own log file(s)? And in this case you
> might want to keep the original framework's default logging behavior.
> Don't know of such case in reality, but it popped to my mind thinking
> about how the Cargo plugin works. It embeds an app server or web
> container and that container could be using slf4j already. Currently
> Cargo only supports Jetty in embedded mode though, and I don't know if
> Jetty uses slf4j or some other logging framework/API.
>
> If all logging from the embedded framework gets directed to the Maven
> output console, it could get messy. I'm thinking something like how
> the surefire plugin works where the user is directed to the surefire
> reports for further problem info (stacktraces etc.)
>
> Well, just some thoughts.
>
> /Anders
>
>>
>>
>> --
>> Ceki
>> 65% of statistics are made up on the spot
>>
>> ---------------------------------------------------------------------
>> 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
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
Re: Merged or separated logs WAS: SLF4J integration
Posted by Anders Hammar <an...@hammar.net>.
> In the context of Maven, is there any added value in pluging having a
> separated logging environment? If there is no added value, then merged
> logging is the way to go.
Could one possible case be a plugin which embeds some "framework"
which uses slf4j to log to it's own log file(s)? And in this case you
might want to keep the original framework's default logging behavior.
Don't know of such case in reality, but it popped to my mind thinking
about how the Cargo plugin works. It embeds an app server or web
container and that container could be using slf4j already. Currently
Cargo only supports Jetty in embedded mode though, and I don't know if
Jetty uses slf4j or some other logging framework/API.
If all logging from the embedded framework gets directed to the Maven
output console, it could get messy. I'm thinking something like how
the surefire plugin works where the user is directed to the surefire
reports for further problem info (stacktraces etc.)
Well, just some thoughts.
/Anders
>
>
> --
> Ceki
> 65% of statistics are made up on the spot
>
> ---------------------------------------------------------------------
> 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: Merged or separated logs WAS: SLF4J integration
Posted by ceki <ce...@qos.ch>.
On 12.10.2012 00:01, Jason van Zyl wrote:
> Ceki made some sample plugins and we'll post something tomorrow about
> some options for integration. Basically Merged vs Mixed: do we want to
> funnel everything into the the core logging backend, or let the plugin
> completely decided by declaring both the API and implementation. The
> outcome of this discussion will determine how to export (or not)
> packages from the core.
I prefer to use the term "separated" logging to "mixed" logging.
Now is a good time to discuss the "merged" vs. "separated" logging
strategies for Maven.
In the "merged" strategy, all logging goes through the slf4j-api
instance created by maven-core, regardless of slf4j-related dependency
declarations in a given plugin. In the "separated" strategy, a given
plugin gets its own separate logging environment by declaring
slf4j-related dependencies.
The "separated" strategy raises the issue of whether getLog() and
injected SLF4J loggers should be attached to the maven-core logging
environment or the plugin's own logging environment.
I am a big fan of "separated" logging strategy in application servers
where forced merging the logs of all applications with the logs of the
server is rather counter-intuitive not to say counter-productive. In
the case of Maven however, I fail to see the added value in letting a
given plugin have a separated logging environment.
"Merged" logging offers the following advantages:
1) a very simple mental model for logging in Maven
2) seems that it is already implemented in trunk
3) few possible surprises in the future.
and the following disadvantages:
1) the logging behavior of existing plugins (those declaring
dependencies on slf4j) will change, i.e. merged into maven-core
logging
2) relatively heavy handed approach
In the context of Maven, is there any added value in pluging having a
separated logging environment? If there is no added value, then merged
logging is the way to go.
--
Ceki
65% of statistics are made up on the spot
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Jason van Zyl <ja...@tesla.io>.
Just an update. Everything is happy again:
https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6/182/console
I worked with Ceki to push out another version of SLF4J Simple which allows the customization of the WARN label. In our case, the ITs we have specifically look for "WARNING" so a property was added to SLF4J Simple and I updated our configuration.
Ceki made some sample plugins and we'll post something tomorrow about some options for integration. Basically Merged vs Mixed: do we want to funnel everything into the the core logging backend, or let the plugin completely decided by declaring both the API and implementation. The outcome of this discussion will determine how to export (or not) packages from the core.
I will also look at the transfer listener. I funneled the events into the logging mechanism but for a console build I can detach the download events from the logging system when run on the console so the output isn't ugly, but in batch mode you probably want the download info captured so maybe there it should still be funneled into the logging backend.
Anyway, that's the update.
On Oct 11, 2012, at 4:44 PM, Jason van Zyl <ja...@tesla.io> wrote:
>
> On Oct 11, 2012, at 4:26 PM, ceki <ce...@qos.ch> wrote:
>
>> Hello all,
>>
>> I've created a trivial plugin which uses slf4j for logging:
>>
>> https://github.com/ceki/foo-plugin
>>
>> It declares a dependency on slf4j-api and slf4j-jdk14
>>
>> Here are my observations:
>>
>> 1) when running with maven 3.0.3 the slf4j declaration is honored,
>> i.e. logging goes through jul (slf4j-jdk14)
>>
>> 2) when running with maven 3.1-SNAPSHOT, the foo-plugins dependency
>> declaration on slf4j-api and binding are simply ignored. Everything
>> goes to slf4j-simple (the binding used by Maven)
>>
>
> This is expected right now with the configuration of the realms currently there.
>
>>
>> I find this second result quite surprising. Apparently, this is
>> because Maven 3.1-SNAPSHOT exports the slf4j packages overriding the
>> plugin dependency declarations on slf4j.
>>
>> In both scenarios, no exceptions are thrown.
>>
>> You are welcome to conduct your own tests.
>>
>
> I think the path forward is probably one of being explicit.
>
> If you have a simple plugin with no real components or much integration then relying on the Mojo.getLog() method will likely suffice.
>
> If you want to specifically use SLF4J then we should probably tell people they have to specify the API JAR and the implementation JAR. Basically if you use it, you know you're using it. I can retract the export of the SLF4J packages from the core. Otherwise we get into magic of trying to detect whether an implementation is specified or not, and provide one from the core if it's not provided and that's just too magical in my opinion. I don't think it's that onerous if you choose to use SLF4J you make both dependency declarations on the API and implementation.
>
> Thoughts?
>
>> Best regards,
>>
>> --
>> Ceki
>> 65% of statistics are made up on the spot
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Our achievements speak for themselves. What we have to keep track
> of are our failures, discouragements and doubts. We tend to forget
> the past difficulties, the many false starts, and the painful
> groping. We see our past achievements as the end result of a
> clean forward thrust, and our present difficulties as
> signs of decline and decay.
>
> -- Eric Hoffer, Reflections on the Human Condition
>
>
>
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Re: SLF4J integration
Posted by Jason van Zyl <ja...@tesla.io>.
On Oct 11, 2012, at 4:26 PM, ceki <ce...@qos.ch> wrote:
> Hello all,
>
> I've created a trivial plugin which uses slf4j for logging:
>
> https://github.com/ceki/foo-plugin
>
> It declares a dependency on slf4j-api and slf4j-jdk14
>
> Here are my observations:
>
> 1) when running with maven 3.0.3 the slf4j declaration is honored,
> i.e. logging goes through jul (slf4j-jdk14)
>
> 2) when running with maven 3.1-SNAPSHOT, the foo-plugins dependency
> declaration on slf4j-api and binding are simply ignored. Everything
> goes to slf4j-simple (the binding used by Maven)
>
This is expected right now with the configuration of the realms currently there.
>
> I find this second result quite surprising. Apparently, this is
> because Maven 3.1-SNAPSHOT exports the slf4j packages overriding the
> plugin dependency declarations on slf4j.
>
> In both scenarios, no exceptions are thrown.
>
> You are welcome to conduct your own tests.
>
I think the path forward is probably one of being explicit.
If you have a simple plugin with no real components or much integration then relying on the Mojo.getLog() method will likely suffice.
If you want to specifically use SLF4J then we should probably tell people they have to specify the API JAR and the implementation JAR. Basically if you use it, you know you're using it. I can retract the export of the SLF4J packages from the core. Otherwise we get into magic of trying to detect whether an implementation is specified or not, and provide one from the core if it's not provided and that's just too magical in my opinion. I don't think it's that onerous if you choose to use SLF4J you make both dependency declarations on the API and implementation.
Thoughts?
> Best regards,
>
> --
> Ceki
> 65% of statistics are made up on the spot
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
Re: SLF4J integration
Posted by ceki <ce...@qos.ch>.
Hello all,
I've created a trivial plugin which uses slf4j for logging:
https://github.com/ceki/foo-plugin
It declares a dependency on slf4j-api and slf4j-jdk14
Here are my observations:
1) when running with maven 3.0.3 the slf4j declaration is honored,
i.e. logging goes through jul (slf4j-jdk14)
2) when running with maven 3.1-SNAPSHOT, the foo-plugins dependency
declaration on slf4j-api and binding are simply ignored. Everything
goes to slf4j-simple (the binding used by Maven)
I find this second result quite surprising. Apparently, this is
because Maven 3.1-SNAPSHOT exports the slf4j packages overriding the
plugin dependency declarations on slf4j.
In both scenarios, no exceptions are thrown.
You are welcome to conduct your own tests.
Best regards,
--
Ceki
65% of statistics are made up on the spot
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Olivier Lamy <ol...@apache.org>.
2012/10/11 Benson Margulies <bi...@gmail.com>:
> On Thu, Oct 11, 2012 at 11:08 AM, Mark Struberg <st...@yahoo.de> wrote:
>> Benson, it's a pity that this happened to you, and I blame it on some plugin bug which should get fixed. Forcing a maven upgrade just because something is buggy is not a serious option. It's ok for well intended new features, but not if it's just a matter of a bug.
>>
>> And knowingly breaking tons of existing builds is not an option neither imo. And this is what Jasons commit did. And it was not even a commented feature commit but a 'side effect' of the (btw broken as well afaik) @Inject enabling commit. This would be a nightmare for thousands of company users which are not allowed to update their build infrastructure that easily.
>
> 'tons of existing builds'? Mark, you continue to claim that slf4j
> dependencies are think on the ground, but offer no evidence. And it's
> not a 'break', in my opinion, to say that a X.Y release is not
> completely backwards compatible. No one is forced to use the new
> version. They can transition when its convenient.
>
> Having flexibility to change the logging back end is a positive value
> to the overall maven platform, and i'm prepared to go along with this
> plan, which accepts some possible inconvenience to some adopters as
> the price of it. If there were lots of other people agreeing with you,
> I'd be OK with looking for a stronger isolation technique to insulate
> the maven core's decision about how to route log messages from the
> decision of any one plugin. Right now, it appears (and perhaps I'm
> misreading the sense of the discussion) that you're the only person
> unhappy with this plan.
>
> Also, could someone please clarify for me whether slf4j changes have
> been committed to the trunk, or merely to a branch? I'm afraid that
> I've got two topics mixed up in my head.
>
> As for my problem with the buildnumber build, until someone explains
> it, we know nothing. I put it out there as evidence that something,
> somewhere, in the build of that touched sl4fj long before JvZ did
> anything discussed here, and I thought that perhaps someone might be
> interested in working out "what".
looks to be an issue an issue with extension in maven 2 for webdav.
Is there any issue for that ?
>
>
>
>>
>>
>> To short version: the current trunk is broken and there is no benefit by exposing slf4j in the near future.
>>
>> The slightly longer version:
>>
>> Any builds with a plugin dependency on slf4j < 1.6 is broken with the current trunk and will blow up. Even Ceki admitted that.
>>
>> There is a possible fix by isolating all plugins which provide slf4j logging themself. But then those plugins will NOT use mavens slf4j logging anymore but their own. So for all those plugins the slf4j provided by maven is useless.
>>
>>
>> And if a plugin uses slf4j for logging and does NOT provide an own slf4j backend, then it will be broken with _all_ already existing maven versions. And there is not even a migration path between those 2 modes.
>>
>> If we expose the slf4j api now, then you would need to wait approximately 2 years before any plugins can start using it. 2 years is a long time in the computer industry...
>>
>>
>> Again, this has _nothing_ to do with slf4j! I would also be -1 for exposing commons-logging, log4j or any other existing logging framework which could exist
>>
>> in user plugins! They just introduce classloader problems alltogether.
>>
>>
>> The only framework which might be ok would java.util.logging. Yea jul sucks as hell and if used badly it creates permgen issues and other side effects. But at least it doesnt create class clashes.
>>
>> The best we could do is to provide a maven.plugin.Logger backend for slf4j.
>>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Benson Margulies <bi...@gmail.com>
>>> To: Maven Developers List <de...@maven.apache.org>; Mark Struberg <st...@yahoo.de>
>>> Cc:
>>> Sent: Thursday, October 11, 2012 2:14 PM
>>> Subject: Re: SLF4J integration
>>>
>>> 1. I have an example of something. I don't quite know what.
>>>
>>> I went to release the buildnumber-maven-plugin from the mojo project,
>>> using 2.2.1. I got a murky error about slf4j, followed by a failure to
>>> find a 'dav' transport.
>>>
>>> So I patched in wagon-dav, and I now the only problem was the slf4j
>>> complaint. So I want with 3.0.4, and all was well.
>>>
>>> 2. Let's keep this in perspective: worst case: some plugin doesn't
>>> work with 3.1 until adjusted. Unless the claim is that there is no
>>> simple or practical adjustment fot some reasonable case, this doesn't
>>> bother me.
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Benson Margulies <bi...@gmail.com>.
On Thu, Oct 11, 2012 at 11:08 AM, Mark Struberg <st...@yahoo.de> wrote:
> Benson, it's a pity that this happened to you, and I blame it on some plugin bug which should get fixed. Forcing a maven upgrade just because something is buggy is not a serious option. It's ok for well intended new features, but not if it's just a matter of a bug.
>
> And knowingly breaking tons of existing builds is not an option neither imo. And this is what Jasons commit did. And it was not even a commented feature commit but a 'side effect' of the (btw broken as well afaik) @Inject enabling commit. This would be a nightmare for thousands of company users which are not allowed to update their build infrastructure that easily.
'tons of existing builds'? Mark, you continue to claim that slf4j
dependencies are think on the ground, but offer no evidence. And it's
not a 'break', in my opinion, to say that a X.Y release is not
completely backwards compatible. No one is forced to use the new
version. They can transition when its convenient.
Having flexibility to change the logging back end is a positive value
to the overall maven platform, and i'm prepared to go along with this
plan, which accepts some possible inconvenience to some adopters as
the price of it. If there were lots of other people agreeing with you,
I'd be OK with looking for a stronger isolation technique to insulate
the maven core's decision about how to route log messages from the
decision of any one plugin. Right now, it appears (and perhaps I'm
misreading the sense of the discussion) that you're the only person
unhappy with this plan.
Also, could someone please clarify for me whether slf4j changes have
been committed to the trunk, or merely to a branch? I'm afraid that
I've got two topics mixed up in my head.
As for my problem with the buildnumber build, until someone explains
it, we know nothing. I put it out there as evidence that something,
somewhere, in the build of that touched sl4fj long before JvZ did
anything discussed here, and I thought that perhaps someone might be
interested in working out "what".
>
>
> To short version: the current trunk is broken and there is no benefit by exposing slf4j in the near future.
>
> The slightly longer version:
>
> Any builds with a plugin dependency on slf4j < 1.6 is broken with the current trunk and will blow up. Even Ceki admitted that.
>
> There is a possible fix by isolating all plugins which provide slf4j logging themself. But then those plugins will NOT use mavens slf4j logging anymore but their own. So for all those plugins the slf4j provided by maven is useless.
>
>
> And if a plugin uses slf4j for logging and does NOT provide an own slf4j backend, then it will be broken with _all_ already existing maven versions. And there is not even a migration path between those 2 modes.
>
> If we expose the slf4j api now, then you would need to wait approximately 2 years before any plugins can start using it. 2 years is a long time in the computer industry...
>
>
> Again, this has _nothing_ to do with slf4j! I would also be -1 for exposing commons-logging, log4j or any other existing logging framework which could exist
>
> in user plugins! They just introduce classloader problems alltogether.
>
>
> The only framework which might be ok would java.util.logging. Yea jul sucks as hell and if used badly it creates permgen issues and other side effects. But at least it doesnt create class clashes.
>
> The best we could do is to provide a maven.plugin.Logger backend for slf4j.
>
>
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
>> From: Benson Margulies <bi...@gmail.com>
>> To: Maven Developers List <de...@maven.apache.org>; Mark Struberg <st...@yahoo.de>
>> Cc:
>> Sent: Thursday, October 11, 2012 2:14 PM
>> Subject: Re: SLF4J integration
>>
>> 1. I have an example of something. I don't quite know what.
>>
>> I went to release the buildnumber-maven-plugin from the mojo project,
>> using 2.2.1. I got a murky error about slf4j, followed by a failure to
>> find a 'dav' transport.
>>
>> So I patched in wagon-dav, and I now the only problem was the slf4j
>> complaint. So I want with 3.0.4, and all was well.
>>
>> 2. Let's keep this in perspective: worst case: some plugin doesn't
>> work with 3.1 until adjusted. Unless the claim is that there is no
>> simple or practical adjustment fot some reasonable case, this doesn't
>> bother me.
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Mark Struberg <st...@yahoo.de>.
Benson, it's a pity that this happened to you, and I blame it on some plugin bug which should get fixed. Forcing a maven upgrade just because something is buggy is not a serious option. It's ok for well intended new features, but not if it's just a matter of a bug.
And knowingly breaking tons of existing builds is not an option neither imo. And this is what Jasons commit did. And it was not even a commented feature commit but a 'side effect' of the (btw broken as well afaik) @Inject enabling commit. This would be a nightmare for thousands of company users which are not allowed to update their build infrastructure that easily.
To short version: the current trunk is broken and there is no benefit by exposing slf4j in the near future.
The slightly longer version:
Any builds with a plugin dependency on slf4j < 1.6 is broken with the current trunk and will blow up. Even Ceki admitted that.
There is a possible fix by isolating all plugins which provide slf4j logging themself. But then those plugins will NOT use mavens slf4j logging anymore but their own. So for all those plugins the slf4j provided by maven is useless.
And if a plugin uses slf4j for logging and does NOT provide an own slf4j backend, then it will be broken with _all_ already existing maven versions. And there is not even a migration path between those 2 modes.
If we expose the slf4j api now, then you would need to wait approximately 2 years before any plugins can start using it. 2 years is a long time in the computer industry...
Again, this has _nothing_ to do with slf4j! I would also be -1 for exposing commons-logging, log4j or any other existing logging framework which could exist
in user plugins! They just introduce classloader problems alltogether.
The only framework which might be ok would java.util.logging. Yea jul sucks as hell and if used badly it creates permgen issues and other side effects. But at least it doesnt create class clashes.
The best we could do is to provide a maven.plugin.Logger backend for slf4j.
LieGrue,
strub
----- Original Message -----
> From: Benson Margulies <bi...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>; Mark Struberg <st...@yahoo.de>
> Cc:
> Sent: Thursday, October 11, 2012 2:14 PM
> Subject: Re: SLF4J integration
>
> 1. I have an example of something. I don't quite know what.
>
> I went to release the buildnumber-maven-plugin from the mojo project,
> using 2.2.1. I got a murky error about slf4j, followed by a failure to
> find a 'dav' transport.
>
> So I patched in wagon-dav, and I now the only problem was the slf4j
> complaint. So I want with 3.0.4, and all was well.
>
> 2. Let's keep this in perspective: worst case: some plugin doesn't
> work with 3.1 until adjusted. Unless the claim is that there is no
> simple or practical adjustment fot some reasonable case, this doesn't
> bother me.
>
> ---------------------------------------------------------------------
> 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: SLF4J integration
Posted by Benson Margulies <bi...@gmail.com>.
1. I have an example of something. I don't quite know what.
I went to release the buildnumber-maven-plugin from the mojo project,
using 2.2.1. I got a murky error about slf4j, followed by a failure to
find a 'dav' transport.
So I patched in wagon-dav, and I now the only problem was the slf4j
complaint. So I want with 3.0.4, and all was well.
2. Let's keep this in perspective: worst case: some plugin doesn't
work with 3.1 until adjusted. Unless the claim is that there is no
simple or practical adjustment fot some reasonable case, this doesn't
bother me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Mark Struberg <st...@yahoo.de>.
Thanks Tamás!
In hindsight of backward compatibility a plugin would always need to add slf4j-api and a logging backend. Otherwise it would not run with <= mvn-3.0.4 , right? Which means that our classloader isolation trick would always trigger?
Feels like I miss something...
LieGrue,
strub
----- Original Message -----
> From: Tamás Cservenák <ta...@cservenak.net>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Thursday, October 11, 2012 1:39 PM
> Subject: Re: SLF4J integration
>
> Here is one with slf4j + logback:
>
> https://github.com/sonatype/nexus-maven-plugins/tree/master/nexus-staging-maven-plugin
>
> and the logging related bits (like LogbackUtils) used in mojos are here:
> https://github.com/sonatype/mojo-commons
>
> Purpose of it: this plugin makes use of a SISU component (not maven
> specific) that uses SLF4J for logging:
> https://github.com/sonatype/spice-zapper
>
>
> Again, the plugin does not use SLF4J for logging, it uses Mojo Log as
> recommended by docs.
>
> But, the SISU component embedded and used within Mojo execution does use
> SLF4J API (only!).
> Clearly, logback is here to provide SLF4J backend, and is synced with Maven
> logging level + some trickery as component is bit too "chatty" at INFO
> level.
>
> https://github.com/sonatype/nexus-maven-plugins/blob/master/nexus-staging-maven-plugin/src/main/java/org/sonatype/nexus/maven/staging/deploy/strategy/ImageDeployStrategy.java#L141
>
>
> Thanks,
> ~t~
>
>
> On Thu, Oct 11, 2012 at 1:26 PM, ceki <ce...@qos.ch> wrote:
>
>> On 11.10.2012 12:43, Mark Struberg wrote:
>>
>> > ceki, really, this is perfect example why no container uses
>> > commons-logging anymore. Do you like to repeat these errors?
>> >
>> > I reiterate: there is a workaround by isolating this in
>> > ClassWorlds. It is not yet there, but ff we like to use slf4j then we
>> > will need to implement that.
>>
>> How about looking at actual plugins? Do you have examples of plugins
>> declaring a dependency on slf4j? Anyone else?
>>
>>
>> --
>> Ceki
>> 65% of statistics are made up on the spot
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail:
> dev-unsubscribe@maven.apache.**org<de...@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: SLF4J integration
Posted by Tamás Cservenák <ta...@cservenak.net>.
Here is one with slf4j + logback:
https://github.com/sonatype/nexus-maven-plugins/tree/master/nexus-staging-maven-plugin
and the logging related bits (like LogbackUtils) used in mojos are here:
https://github.com/sonatype/mojo-commons
Purpose of it: this plugin makes use of a SISU component (not maven
specific) that uses SLF4J for logging:
https://github.com/sonatype/spice-zapper
Again, the plugin does not use SLF4J for logging, it uses Mojo Log as
recommended by docs.
But, the SISU component embedded and used within Mojo execution does use
SLF4J API (only!).
Clearly, logback is here to provide SLF4J backend, and is synced with Maven
logging level + some trickery as component is bit too "chatty" at INFO
level.
https://github.com/sonatype/nexus-maven-plugins/blob/master/nexus-staging-maven-plugin/src/main/java/org/sonatype/nexus/maven/staging/deploy/strategy/ImageDeployStrategy.java#L141
Thanks,
~t~
On Thu, Oct 11, 2012 at 1:26 PM, ceki <ce...@qos.ch> wrote:
> On 11.10.2012 12:43, Mark Struberg wrote:
>
> > ceki, really, this is perfect example why no container uses
> > commons-logging anymore. Do you like to repeat these errors?
> >
> > I reiterate: there is a workaround by isolating this in
> > ClassWorlds. It is not yet there, but ff we like to use slf4j then we
> > will need to implement that.
>
> How about looking at actual plugins? Do you have examples of plugins
> declaring a dependency on slf4j? Anyone else?
>
>
> --
> Ceki
> 65% of statistics are made up on the spot
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: SLF4J integration
Posted by ceki <ce...@qos.ch>.
On 11.10.2012 12:43, Mark Struberg wrote:
> ceki, really, this is perfect example why no container uses
> commons-logging anymore. Do you like to repeat these errors?
>
> I reiterate: there is a workaround by isolating this in
> ClassWorlds. It is not yet there, but ff we like to use slf4j then we
> will need to implement that.
How about looking at actual plugins? Do you have examples of plugins
declaring a dependency on slf4j? Anyone else?
--
Ceki
65% of statistics are made up on the spot
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Mark Struberg <st...@yahoo.de>.
ceki, really, this is perfect example why no container uses commons-logging anymore.
Do you like to repeat these errors?
I reiterate: there is a workaround by isolating this in ClassWorlds. It is not yet there, but ff we like to use slf4j then we will need to implement that.
LieGrue,
strub
----- Original Message -----
> From: ceki <ce...@qos.ch>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Thursday, October 11, 2012 12:25 PM
> Subject: Re: SLF4J integration
>
> On 11.10.2012 11:18, Mark Struberg wrote:
>> Oh I missed one more constellation
>>
>> a plugin could have slf4j-1.5.x + a logging backend we do not know of.
>>
>> I hope such things dont often exist, but in theory it could happen.
>>
>> For all of those cases we need isolation.
>
> A few months before creating the SLF4J project, I had a lengthy
> conversation on the commons-dev mailing list about logging scenarios.
> Richard Sitze (from IBM) offered a number of complex scenarios, and
> that's when the penny finally dropped for me [1]. It is a waste of time
> catering for all imaginable logging scenarios. The space of possible
> logging scenarios is truly vast. However, only a very limited number of
> these scenarios occur in practice. It makes more sense to concentrate
> on the common scenarios to ensure that they are well supported.
>
> More concretely, I propose that we find one or two examples of plugins
> declaring an slf4j dependency and test these plugins with the upcoming
> version of maven (the one using slf4j).
>
> [1] http://marc.info/?t=110780972600001&r=1&w=2
>
> --
> Ceki
> 65% of statistics are made up on the spot
>
> ---------------------------------------------------------------------
> 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: SLF4J integration
Posted by ceki <ce...@qos.ch>.
On 11.10.2012 11:18, Mark Struberg wrote:
> Oh I missed one more constellation
>
> a plugin could have slf4j-1.5.x + a logging backend we do not know of.
>
> I hope such things dont often exist, but in theory it could happen.
>
> For all of those cases we need isolation.
A few months before creating the SLF4J project, I had a lengthy
conversation on the commons-dev mailing list about logging scenarios.
Richard Sitze (from IBM) offered a number of complex scenarios, and
that's when the penny finally dropped for me [1]. It is a waste of time
catering for all imaginable logging scenarios. The space of possible
logging scenarios is truly vast. However, only a very limited number of
these scenarios occur in practice. It makes more sense to concentrate
on the common scenarios to ensure that they are well supported.
More concretely, I propose that we find one or two examples of plugins
declaring an slf4j dependency and test these plugins with the upcoming
version of maven (the one using slf4j).
[1] http://marc.info/?t=110780972600001&r=1&w=2
--
Ceki
65% of statistics are made up on the spot
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Mark Struberg <st...@yahoo.de>.
Oh I missed one more constellation
a plugin could have slf4j-1.5.x + a logging backend we do not know of.
I hope such things dont often exist, but in theory it could happen.
For all of those cases we need isolation.
LieGrue,
strub
----- Original Message -----
> From: Mark Struberg <st...@yahoo.de>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Thursday, October 11, 2012 10:52 AM
> Subject: Re: SLF4J integration
>
> A the end of the day we could have both actually!
>
> Most plugins will add both as dependency. Otherwise they would not be able to
> log via slf4j.
>
> But there are also libraries like OpenJPA (via openjpa-maven-plugin) which do
> auto detection. They look up what impls are available and decide what to use. In
> OpenJPA you can even force the one you like to use via a property in
> persistence.xml. So in the real world it's even more complicated.
>
> I'm not sure how to translate "Das Leben ist kein
> Kindergeburtstag" - literally it would be "live is no children
> birthday" ;)
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Anders Hammar <an...@hammar.net>
>> To: Maven Developers List <de...@maven.apache.org>
>> Cc:
>> Sent: Thursday, October 11, 2012 10:24 AM
>> Subject: Re: SLF4J integration
>>
>> Just to get this clear in my head:
>> When you're talking about "slf4j dependency" in a plugin, are
> you
>> talking about dependency to slf4j-api or an slf4j impl?
>>
>> /Anders
>>
>> On Thu, Oct 11, 2012 at 10:16 AM, ceki <ce...@qos.ch> wrote:
>>> On 11.10.2012 08:37, Mark Struberg wrote:
>>>
>>> Hi Mark,
>>>
>>>> Hi Ceki, thanks for the reply!
>>>
>>>
>>>>> The method signatures of classes in the org.slf4j package such
> as?
>>>>> Logger, LoggerFactory, Marker, MDC, etc. are the same since
> 2005.?
>>>>
>>>> No they are not. I did a diff between 1.2 and the latest and it
>>>> seems a few trace() methods got added. This is only a minor
> problem
>>>> but still. This change is perfectly backward compatible, but
> it's
>> not
>>>> forward compatible. If there is any new signature added/changed in
> a
>>>> newer version which we will not yet use, then we would just crash
> if a
>>>> plugin uses the newer version. Now this is highly unlikely. But
>> I've
>>>> seen this with commons logging and I've seen this with the
>>>> LocationAwareLoger as you already mentioned below. This is btw
> exactly
>>>> the reason why we shade in all commons-* stuff to private
> packages...
>>>
>>> Correct. The trace method was added in SLF4J version 1.4 released on
>>> May 16th 2007. Interestingly enough, I can't remember a single
>>> complaint about missing trace method. About 1% of slf4j-users use
>>> versions earlier than 1.4. Among that 1%, even fewer have a dependency
>>> requiring the trace method. As an end result, and as far as I can
>>> tell, no one complains about the missing trace method in earlier slf4j
>>> versions.
>>>
>>> My point is that there are some imaginary problems that never occur in
>>> practice. In practice, the slf4j version some software is compiled
>>> with is never a problem assuming it only imports from the org.slf4j
>>> package.
>>>
>>>>> this means that the minor version of the SLF4J binding
>>>>> must match that of the slf4j-api. The "maintenance"
>>>>> number is unimportant.
>>>>
>>>
>>>> That's perfectly fine that way! Please understand that this is
>>>> nothing against slf4j! I just like to avoid that we introduce
> build
>>>> problems to existing projects. As highlighted in my previous post
>>>> there ARE ways to do that (by shielding via ClassWorlds), but this
> is
>>>> not in place in trunk yet. Also there are zero integration tests
> for
>>>> it atm!
>>>
>>> OK.
>>>
>>>> Maven uses a child-first classloading strategy (with exceptions) -
> a
>>>> plugin would only see exactly 1 version. Currently (again: there
> is
>>>> atm no shielding in place yet) if a plugin would would provide
> it's
>>>> own slf4j-api-1.4.2 then the plugin would get this version of the
>>>> Class. And if the plugin would invoke
>>>> LoggerFactory.getLogger(this.class()) then what would happen? Most
>>>> probably a classcast exception, right? There is a minor chance
> that we
>>>> do not blow up as there is a complex ClassLoading environment in
>>>> place. But we only know after we have some IT in place which do
> not
>>>> exist yet. All the change got committed without a single IT, thus
> my
>>>> -1 in the first place.
>>>
>>>
>>> While I agree with the gist of your argument, I still maintain that
>>> "slf4j versions" is not the crux of the matter here.
> However, as
>> you
>>> point out, class isolation should be implemented and tested.
>>>
>>>>
>>>>>> 2.) if you use slf4j, then ALL the funnels and logging
> backends
>> must
>>>>>> have the very same version number than the slf4j-api.
> Otherwise
>> you
>>>>>> are pretty much doomed. Ceki, is this correct as well?
>>>>>
>>>>>
>>>>> I would not go as far as "doomed". For example, the
>> following
>>>>> combination will work fine: slf4j-api-1.7.2.jar,
>>>>> sfl4j-simple-1.6.5.jar, log4j-over-slf4j-1.6.2.jar,
>>>>> jcl-ocer-slf4j-1.7.1.jar and jul-to-slf4j-1.6.0.jar. In other
>> words,
>>>>> you can freely mix artifacts in the 1.6.x and 1.7.x families.
>>>
>>>
>>>> But can you freely mix 1.5.x and 1.6.x? or 1.7 and 1.5 or 1.4? No
>>>> you cannot as far as I've seen. So we cannot make a general
>> assumption
>>>> on that! The only safe rule is to not mix slf4j parts with
> diverging
>>>> major or minor number. Is this correct?
>>>
>>> Yes, that is correct.
>>>
>>>
>>>>
>>>>> Sounds good. I would recommend isolation regardless of the
> version
>> of
>>>>> the discovered slf4j dependency. The plugin author probably
> wishes
>>>>> logging isolation. Maven should let the plugin have its own
>> separate
>>>>> logging environment distinct from Maven's own logging.
>>>
>>>
>>>> But that would actually be a big step backwards imo.
>>>
>>> No, separating maven logging and plugin logging (for the plugins that
>>> explicitly set their own slf4j logging environment) is not a step
>>> backwards. On the contrary, it preserves existing behavior.
>>>
>>> In my earlier message, I apparently did not insist enough on the the
>>> point that isolation was only required for the minority of plugins
>>> which set up their own slf4j-based logging environment. The vast
>>> majority of plugins which do not declare an slf4j dependency, would
>>> get their slf4j loggers either via injection or via getLogger().
>>>
>>>> Currently any plugin is forced to 'funnel' the output into
> the
>>>> logger it obtains via getLogger() itself. This is an instance of
>>>> org.apache.maven.plugin.logging.Log and we have it perfectly under
> our
>>>> own control. It's not a perfectly convenient logging api but
> it
>> works
>>>> and shields us from all implementation details!
>>>
>>> This has been discussed earlier so I won't respond.
>>>
>>>> If we would isolate away all the logging of a plugin (because it
>>>> contains a diverging slf4j version) then we would loose all this
> logs,
>>>> right?
>>>
>>> Of course not. The logs would be available in the logging environment
>>> proper to the plugin (declaring its own logging environment),
> that's
>>> the beauty of this approach.
>>>
>>>> It is perfectly valid for any plugin to use slf4j right now.
>>>
>>>
>>> Absolutely.
>>>
>>>> All it needs to do is to funnel it into our own maven logging
>>>> api. We could e.g. provide a slf4j-maven-logging backend so users
>>>> could use it even more easily.
>>>
>>>
>>> I think that's an understandable mistake but a mistake
> nonetheless. We
>>> don't want to funnel plugin logging (for a plugin declaring its
> own
>>> slf4j dependencies) into Maven logging. For one, that's not the
>>> *current* behavior as Maven logging and plugin logging (depending on
>>> slf4j) are obviously independent. For two, attempts at such
> integration
>>> quickly become insurmountably complex. Logging integration between
>>> Maven and a pluging declaring its own slf4j dependencies is not needed
>>> and certainly not worth the effort.
>>>
>>> If unconvinced, I suggest we study concrete examples.
>>>
>>> --
>>> Ceki
>>> 65% of statistics are made up on the spot
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> ---------------------------------------------------------------------
> 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: SLF4J integration
Posted by Mark Struberg <st...@yahoo.de>.
A the end of the day we could have both actually!
Most plugins will add both as dependency. Otherwise they would not be able to log via slf4j.
But there are also libraries like OpenJPA (via openjpa-maven-plugin) which do auto detection. They look up what impls are available and decide what to use. In OpenJPA you can even force the one you like to use via a property in persistence.xml. So in the real world it's even more complicated.
I'm not sure how to translate "Das Leben ist kein Kindergeburtstag" - literally it would be "live is no children birthday" ;)
LieGrue,
strub
----- Original Message -----
> From: Anders Hammar <an...@hammar.net>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Thursday, October 11, 2012 10:24 AM
> Subject: Re: SLF4J integration
>
> Just to get this clear in my head:
> When you're talking about "slf4j dependency" in a plugin, are you
> talking about dependency to slf4j-api or an slf4j impl?
>
> /Anders
>
> On Thu, Oct 11, 2012 at 10:16 AM, ceki <ce...@qos.ch> wrote:
>> On 11.10.2012 08:37, Mark Struberg wrote:
>>
>> Hi Mark,
>>
>>> Hi Ceki, thanks for the reply!
>>
>>
>>>> The method signatures of classes in the org.slf4j package such as?
>>>> Logger, LoggerFactory, Marker, MDC, etc. are the same since 2005.?
>>>
>>> No they are not. I did a diff between 1.2 and the latest and it
>>> seems a few trace() methods got added. This is only a minor problem
>>> but still. This change is perfectly backward compatible, but it's
> not
>>> forward compatible. If there is any new signature added/changed in a
>>> newer version which we will not yet use, then we would just crash if a
>>> plugin uses the newer version. Now this is highly unlikely. But
> I've
>>> seen this with commons logging and I've seen this with the
>>> LocationAwareLoger as you already mentioned below. This is btw exactly
>>> the reason why we shade in all commons-* stuff to private packages...
>>
>> Correct. The trace method was added in SLF4J version 1.4 released on
>> May 16th 2007. Interestingly enough, I can't remember a single
>> complaint about missing trace method. About 1% of slf4j-users use
>> versions earlier than 1.4. Among that 1%, even fewer have a dependency
>> requiring the trace method. As an end result, and as far as I can
>> tell, no one complains about the missing trace method in earlier slf4j
>> versions.
>>
>> My point is that there are some imaginary problems that never occur in
>> practice. In practice, the slf4j version some software is compiled
>> with is never a problem assuming it only imports from the org.slf4j
>> package.
>>
>>>> this means that the minor version of the SLF4J binding
>>>> must match that of the slf4j-api. The "maintenance"
>>>> number is unimportant.
>>>
>>
>>> That's perfectly fine that way! Please understand that this is
>>> nothing against slf4j! I just like to avoid that we introduce build
>>> problems to existing projects. As highlighted in my previous post
>>> there ARE ways to do that (by shielding via ClassWorlds), but this is
>>> not in place in trunk yet. Also there are zero integration tests for
>>> it atm!
>>
>> OK.
>>
>>> Maven uses a child-first classloading strategy (with exceptions) - a
>>> plugin would only see exactly 1 version. Currently (again: there is
>>> atm no shielding in place yet) if a plugin would would provide it's
>>> own slf4j-api-1.4.2 then the plugin would get this version of the
>>> Class. And if the plugin would invoke
>>> LoggerFactory.getLogger(this.class()) then what would happen? Most
>>> probably a classcast exception, right? There is a minor chance that we
>>> do not blow up as there is a complex ClassLoading environment in
>>> place. But we only know after we have some IT in place which do not
>>> exist yet. All the change got committed without a single IT, thus my
>>> -1 in the first place.
>>
>>
>> While I agree with the gist of your argument, I still maintain that
>> "slf4j versions" is not the crux of the matter here. However, as
> you
>> point out, class isolation should be implemented and tested.
>>
>>>
>>>>> 2.) if you use slf4j, then ALL the funnels and logging backends
> must
>>>>> have the very same version number than the slf4j-api. Otherwise
> you
>>>>> are pretty much doomed. Ceki, is this correct as well?
>>>>
>>>>
>>>> I would not go as far as "doomed". For example, the
> following
>>>> combination will work fine: slf4j-api-1.7.2.jar,
>>>> sfl4j-simple-1.6.5.jar, log4j-over-slf4j-1.6.2.jar,
>>>> jcl-ocer-slf4j-1.7.1.jar and jul-to-slf4j-1.6.0.jar. In other
> words,
>>>> you can freely mix artifacts in the 1.6.x and 1.7.x families.
>>
>>
>>> But can you freely mix 1.5.x and 1.6.x? or 1.7 and 1.5 or 1.4? No
>>> you cannot as far as I've seen. So we cannot make a general
> assumption
>>> on that! The only safe rule is to not mix slf4j parts with diverging
>>> major or minor number. Is this correct?
>>
>> Yes, that is correct.
>>
>>
>>>
>>>> Sounds good. I would recommend isolation regardless of the version
> of
>>>> the discovered slf4j dependency. The plugin author probably wishes
>>>> logging isolation. Maven should let the plugin have its own
> separate
>>>> logging environment distinct from Maven's own logging.
>>
>>
>>> But that would actually be a big step backwards imo.
>>
>> No, separating maven logging and plugin logging (for the plugins that
>> explicitly set their own slf4j logging environment) is not a step
>> backwards. On the contrary, it preserves existing behavior.
>>
>> In my earlier message, I apparently did not insist enough on the the
>> point that isolation was only required for the minority of plugins
>> which set up their own slf4j-based logging environment. The vast
>> majority of plugins which do not declare an slf4j dependency, would
>> get their slf4j loggers either via injection or via getLogger().
>>
>>> Currently any plugin is forced to 'funnel' the output into the
>>> logger it obtains via getLogger() itself. This is an instance of
>>> org.apache.maven.plugin.logging.Log and we have it perfectly under our
>>> own control. It's not a perfectly convenient logging api but it
> works
>>> and shields us from all implementation details!
>>
>> This has been discussed earlier so I won't respond.
>>
>>> If we would isolate away all the logging of a plugin (because it
>>> contains a diverging slf4j version) then we would loose all this logs,
>>> right?
>>
>> Of course not. The logs would be available in the logging environment
>> proper to the plugin (declaring its own logging environment), that's
>> the beauty of this approach.
>>
>>> It is perfectly valid for any plugin to use slf4j right now.
>>
>>
>> Absolutely.
>>
>>> All it needs to do is to funnel it into our own maven logging
>>> api. We could e.g. provide a slf4j-maven-logging backend so users
>>> could use it even more easily.
>>
>>
>> I think that's an understandable mistake but a mistake nonetheless. We
>> don't want to funnel plugin logging (for a plugin declaring its own
>> slf4j dependencies) into Maven logging. For one, that's not the
>> *current* behavior as Maven logging and plugin logging (depending on
>> slf4j) are obviously independent. For two, attempts at such integration
>> quickly become insurmountably complex. Logging integration between
>> Maven and a pluging declaring its own slf4j dependencies is not needed
>> and certainly not worth the effort.
>>
>> If unconvinced, I suggest we study concrete examples.
>>
>> --
>> Ceki
>> 65% of statistics are made up on the spot
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Stephen Connolly <st...@gmail.com>.
On 11 October 2012 10:30, Stephen Connolly
<st...@gmail.com>wrote:
> On 11 October 2012 10:19, ceki <ce...@qos.ch> wrote:
>
>> On 11.10.2012 10:24, Anders Hammar wrote:
>>
>>> Just to get this clear in my head:
>>> When you're talking about "slf4j dependency" in a plugin, are you
>>> talking about dependency to slf4j-api or an slf4j impl?
>>>
>>
>> A plugin declaring a dependency on slf4j-api without declaring a
>> dependency on an implementation does not makes sense imo. It follows
>> that the term "declaring a dependency on slf4j" means a dependency on
>> both slf4j-api as well as a binding, aka implementation.
>>
>
> SINCE 1.6.0 As of SLF4J version 1.6, in the absence of a binding, SLF4J
> will default to a no-operation (NOP) logger implementation.
>
> A plugin might just want to shunt the logs to null and so use the
> side-effect of the NOP logger
>
Note I am not saying that the above is a good idea... just that it might be
the kind of crazy idea loved by superstitious developers [
http://blog.activelylazy.co.uk/2012/10/09/knowledge-vs-superstition/ ]
>
>
>> /Anders
>>>
>>
>> --
>> Ceki
>> 65% of statistics are made up on the spot
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
Re: SLF4J integration
Posted by Stephen Connolly <st...@gmail.com>.
On 11 October 2012 10:19, ceki <ce...@qos.ch> wrote:
> On 11.10.2012 10:24, Anders Hammar wrote:
>
>> Just to get this clear in my head:
>> When you're talking about "slf4j dependency" in a plugin, are you
>> talking about dependency to slf4j-api or an slf4j impl?
>>
>
> A plugin declaring a dependency on slf4j-api without declaring a
> dependency on an implementation does not makes sense imo. It follows
> that the term "declaring a dependency on slf4j" means a dependency on
> both slf4j-api as well as a binding, aka implementation.
>
SINCE 1.6.0 As of SLF4J version 1.6, in the absence of a binding, SLF4J
will default to a no-operation (NOP) logger implementation.
A plugin might just want to shunt the logs to null and so use the
side-effect of the NOP logger
> /Anders
>>
>
> --
> Ceki
> 65% of statistics are made up on the spot
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: SLF4J integration
Posted by ceki <ce...@qos.ch>.
On 11.10.2012 12:17, Anders Hammar wrote:
>> A plugin declaring a dependency on slf4j-api without declaring a
>> dependency on an implementation does not makes sense imo. It follows
>> that the term "declaring a dependency on slf4j" means a dependency on
>> both slf4j-api as well as a binding, aka implementation.
>
> If the get the slf4j logger injected they would only have a slf4j-api
> dependency, wouldn't they? I'm asking as I *think* we said we would
> use slf4j as the logging interface in Maven.
Yes, the maven-core dependency is on slf4j-api, not any particular impl.
Only classes from the org.slf4j package are imported.
> What I'm thinking is that the aim is to allow plugins to use the core
> slf4j logging, right? But we would like to keep any existing behavior
> where a plugin logs to it's own logging file through slf4j, right?
> So then we can't check on a slf4j-api dependency, but need to look for an impl.
If a plugin declares a dependency on say slf4j-jdk14, and assuming dep
declarations in plugins are transitive, than plugin's classloader will
also have classes from slf4j-api.jar in addition to those from
slf4j-jdk14.jar. Thus, when the plugin imports
org.slf4j.LoggerFactory, the instance of LoggerFactory will be bound
to JUL.
I think it makes sense to study actual plugins declaring a dependency
on slf4j, instead of imagining problems which may or may not exist.
--
Ceki
65% of statistics are made up on the spot
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Anders Hammar <an...@hammar.net>.
> A plugin declaring a dependency on slf4j-api without declaring a
> dependency on an implementation does not makes sense imo. It follows
> that the term "declaring a dependency on slf4j" means a dependency on
> both slf4j-api as well as a binding, aka implementation.
If the get the slf4j logger injected they would only have a slf4j-api
dependency, wouldn't they? I'm asking as I *think* we said we would
use slf4j as the logging interface in Maven.
What I'm thinking is that the aim is to allow plugins to use the core
slf4j logging, right? But we would like to keep any existing behavior
where a plugin logs to it's own logging file through slf4j, right?
So then we can't check on a slf4j-api dependency, but need to look for an impl.
Just trying to follow the discussion....
/Anders
>
>> /Anders
>
>
> --
> Ceki
> 65% of statistics are made up on the spot
>
> ---------------------------------------------------------------------
> 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: SLF4J integration
Posted by ceki <ce...@qos.ch>.
On 11.10.2012 10:24, Anders Hammar wrote:
> Just to get this clear in my head:
> When you're talking about "slf4j dependency" in a plugin, are you
> talking about dependency to slf4j-api or an slf4j impl?
A plugin declaring a dependency on slf4j-api without declaring a
dependency on an implementation does not makes sense imo. It follows
that the term "declaring a dependency on slf4j" means a dependency on
both slf4j-api as well as a binding, aka implementation.
> /Anders
--
Ceki
65% of statistics are made up on the spot
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Anders Hammar <an...@hammar.net>.
Just to get this clear in my head:
When you're talking about "slf4j dependency" in a plugin, are you
talking about dependency to slf4j-api or an slf4j impl?
/Anders
On Thu, Oct 11, 2012 at 10:16 AM, ceki <ce...@qos.ch> wrote:
> On 11.10.2012 08:37, Mark Struberg wrote:
>
> Hi Mark,
>
>> Hi Ceki, thanks for the reply!
>
>
>>> The method signatures of classes in the org.slf4j package such as?
>>> Logger, LoggerFactory, Marker, MDC, etc. are the same since 2005.?
>>
>> No they are not. I did a diff between 1.2 and the latest and it
>> seems a few trace() methods got added. This is only a minor problem
>> but still. This change is perfectly backward compatible, but it's not
>> forward compatible. If there is any new signature added/changed in a
>> newer version which we will not yet use, then we would just crash if a
>> plugin uses the newer version. Now this is highly unlikely. But I've
>> seen this with commons logging and I've seen this with the
>> LocationAwareLoger as you already mentioned below. This is btw exactly
>> the reason why we shade in all commons-* stuff to private packages...
>
> Correct. The trace method was added in SLF4J version 1.4 released on
> May 16th 2007. Interestingly enough, I can't remember a single
> complaint about missing trace method. About 1% of slf4j-users use
> versions earlier than 1.4. Among that 1%, even fewer have a dependency
> requiring the trace method. As an end result, and as far as I can
> tell, no one complains about the missing trace method in earlier slf4j
> versions.
>
> My point is that there are some imaginary problems that never occur in
> practice. In practice, the slf4j version some software is compiled
> with is never a problem assuming it only imports from the org.slf4j
> package.
>
>>> this means that the minor version of the SLF4J binding
>>> must match that of the slf4j-api. The "maintenance"
>>> number is unimportant.
>>
>
>> That's perfectly fine that way! Please understand that this is
>> nothing against slf4j! I just like to avoid that we introduce build
>> problems to existing projects. As highlighted in my previous post
>> there ARE ways to do that (by shielding via ClassWorlds), but this is
>> not in place in trunk yet. Also there are zero integration tests for
>> it atm!
>
> OK.
>
>> Maven uses a child-first classloading strategy (with exceptions) - a
>> plugin would only see exactly 1 version. Currently (again: there is
>> atm no shielding in place yet) if a plugin would would provide it's
>> own slf4j-api-1.4.2 then the plugin would get this version of the
>> Class. And if the plugin would invoke
>> LoggerFactory.getLogger(this.class()) then what would happen? Most
>> probably a classcast exception, right? There is a minor chance that we
>> do not blow up as there is a complex ClassLoading environment in
>> place. But we only know after we have some IT in place which do not
>> exist yet. All the change got committed without a single IT, thus my
>> -1 in the first place.
>
>
> While I agree with the gist of your argument, I still maintain that
> "slf4j versions" is not the crux of the matter here. However, as you
> point out, class isolation should be implemented and tested.
>
>>
>>>> 2.) if you use slf4j, then ALL the funnels and logging backends must
>>>> have the very same version number than the slf4j-api. Otherwise you
>>>> are pretty much doomed. Ceki, is this correct as well?
>>>
>>>
>>> I would not go as far as "doomed". For example, the following
>>> combination will work fine: slf4j-api-1.7.2.jar,
>>> sfl4j-simple-1.6.5.jar, log4j-over-slf4j-1.6.2.jar,
>>> jcl-ocer-slf4j-1.7.1.jar and jul-to-slf4j-1.6.0.jar. In other words,
>>> you can freely mix artifacts in the 1.6.x and 1.7.x families.
>
>
>> But can you freely mix 1.5.x and 1.6.x? or 1.7 and 1.5 or 1.4? No
>> you cannot as far as I've seen. So we cannot make a general assumption
>> on that! The only safe rule is to not mix slf4j parts with diverging
>> major or minor number. Is this correct?
>
> Yes, that is correct.
>
>
>>
>>> Sounds good. I would recommend isolation regardless of the version of
>>> the discovered slf4j dependency. The plugin author probably wishes
>>> logging isolation. Maven should let the plugin have its own separate
>>> logging environment distinct from Maven's own logging.
>
>
>> But that would actually be a big step backwards imo.
>
> No, separating maven logging and plugin logging (for the plugins that
> explicitly set their own slf4j logging environment) is not a step
> backwards. On the contrary, it preserves existing behavior.
>
> In my earlier message, I apparently did not insist enough on the the
> point that isolation was only required for the minority of plugins
> which set up their own slf4j-based logging environment. The vast
> majority of plugins which do not declare an slf4j dependency, would
> get their slf4j loggers either via injection or via getLogger().
>
>> Currently any plugin is forced to 'funnel' the output into the
>> logger it obtains via getLogger() itself. This is an instance of
>> org.apache.maven.plugin.logging.Log and we have it perfectly under our
>> own control. It's not a perfectly convenient logging api but it works
>> and shields us from all implementation details!
>
> This has been discussed earlier so I won't respond.
>
>> If we would isolate away all the logging of a plugin (because it
>> contains a diverging slf4j version) then we would loose all this logs,
>> right?
>
> Of course not. The logs would be available in the logging environment
> proper to the plugin (declaring its own logging environment), that's
> the beauty of this approach.
>
>> It is perfectly valid for any plugin to use slf4j right now.
>
>
> Absolutely.
>
>> All it needs to do is to funnel it into our own maven logging
>> api. We could e.g. provide a slf4j-maven-logging backend so users
>> could use it even more easily.
>
>
> I think that's an understandable mistake but a mistake nonetheless. We
> don't want to funnel plugin logging (for a plugin declaring its own
> slf4j dependencies) into Maven logging. For one, that's not the
> *current* behavior as Maven logging and plugin logging (depending on
> slf4j) are obviously independent. For two, attempts at such integration
> quickly become insurmountably complex. Logging integration between
> Maven and a pluging declaring its own slf4j dependencies is not needed
> and certainly not worth the effort.
>
> If unconvinced, I suggest we study concrete examples.
>
> --
> Ceki
> 65% of statistics are made up on the spot
>
> ---------------------------------------------------------------------
> 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: SLF4J integration
Posted by ceki <ce...@qos.ch>.
On 11.10.2012 08:37, Mark Struberg wrote:
Hi Mark,
> Hi Ceki, thanks for the reply!
>> The method signatures of classes in the org.slf4j package such as?
>> Logger, LoggerFactory, Marker, MDC, etc. are the same since 2005.?
>
> No they are not. I did a diff between 1.2 and the latest and it
> seems a few trace() methods got added. This is only a minor problem
> but still. This change is perfectly backward compatible, but it's not
> forward compatible. If there is any new signature added/changed in a
> newer version which we will not yet use, then we would just crash if a
> plugin uses the newer version. Now this is highly unlikely. But I've
> seen this with commons logging and I've seen this with the
> LocationAwareLoger as you already mentioned below. This is btw exactly
> the reason why we shade in all commons-* stuff to private packages...
Correct. The trace method was added in SLF4J version 1.4 released on
May 16th 2007. Interestingly enough, I can't remember a single
complaint about missing trace method. About 1% of slf4j-users use
versions earlier than 1.4. Among that 1%, even fewer have a dependency
requiring the trace method. As an end result, and as far as I can
tell, no one complains about the missing trace method in earlier slf4j
versions.
My point is that there are some imaginary problems that never occur in
practice. In practice, the slf4j version some software is compiled
with is never a problem assuming it only imports from the org.slf4j
package.
>> this means that the minor version of the SLF4J binding
>> must match that of the slf4j-api. The "maintenance"
>> number is unimportant.
>
> That's perfectly fine that way! Please understand that this is
> nothing against slf4j! I just like to avoid that we introduce build
> problems to existing projects. As highlighted in my previous post
> there ARE ways to do that (by shielding via ClassWorlds), but this is
> not in place in trunk yet. Also there are zero integration tests for
> it atm!
OK.
> Maven uses a child-first classloading strategy (with exceptions) - a
> plugin would only see exactly 1 version. Currently (again: there is
> atm no shielding in place yet) if a plugin would would provide it's
> own slf4j-api-1.4.2 then the plugin would get this version of the
> Class. And if the plugin would invoke
> LoggerFactory.getLogger(this.class()) then what would happen? Most
> probably a classcast exception, right? There is a minor chance that we
> do not blow up as there is a complex ClassLoading environment in
> place. But we only know after we have some IT in place which do not
> exist yet. All the change got committed without a single IT, thus my
> -1 in the first place.
While I agree with the gist of your argument, I still maintain that
"slf4j versions" is not the crux of the matter here. However, as you
point out, class isolation should be implemented and tested.
>
>>> 2.) if you use slf4j, then ALL the funnels and logging backends must
>>> have the very same version number than the slf4j-api. Otherwise you
>>> are pretty much doomed. Ceki, is this correct as well?
>>
>> I would not go as far as "doomed". For example, the following
>> combination will work fine: slf4j-api-1.7.2.jar,
>> sfl4j-simple-1.6.5.jar, log4j-over-slf4j-1.6.2.jar,
>> jcl-ocer-slf4j-1.7.1.jar and jul-to-slf4j-1.6.0.jar. In other words,
>> you can freely mix artifacts in the 1.6.x and 1.7.x families.
> But can you freely mix 1.5.x and 1.6.x? or 1.7 and 1.5 or 1.4? No
> you cannot as far as I've seen. So we cannot make a general assumption
> on that! The only safe rule is to not mix slf4j parts with diverging
> major or minor number. Is this correct?
Yes, that is correct.
>
>> Sounds good. I would recommend isolation regardless of the version of
>> the discovered slf4j dependency. The plugin author probably wishes
>> logging isolation. Maven should let the plugin have its own separate
>> logging environment distinct from Maven's own logging.
> But that would actually be a big step backwards imo.
No, separating maven logging and plugin logging (for the plugins that
explicitly set their own slf4j logging environment) is not a step
backwards. On the contrary, it preserves existing behavior.
In my earlier message, I apparently did not insist enough on the the
point that isolation was only required for the minority of plugins
which set up their own slf4j-based logging environment. The vast
majority of plugins which do not declare an slf4j dependency, would
get their slf4j loggers either via injection or via getLogger().
> Currently any plugin is forced to 'funnel' the output into the
> logger it obtains via getLogger() itself. This is an instance of
> org.apache.maven.plugin.logging.Log and we have it perfectly under our
> own control. It's not a perfectly convenient logging api but it works
> and shields us from all implementation details!
This has been discussed earlier so I won't respond.
> If we would isolate away all the logging of a plugin (because it
> contains a diverging slf4j version) then we would loose all this logs,
> right?
Of course not. The logs would be available in the logging environment
proper to the plugin (declaring its own logging environment), that's
the beauty of this approach.
> It is perfectly valid for any plugin to use slf4j right now.
Absolutely.
> All it needs to do is to funnel it into our own maven logging
> api. We could e.g. provide a slf4j-maven-logging backend so users
> could use it even more easily.
I think that's an understandable mistake but a mistake nonetheless. We
don't want to funnel plugin logging (for a plugin declaring its own
slf4j dependencies) into Maven logging. For one, that's not the
*current* behavior as Maven logging and plugin logging (depending on
slf4j) are obviously independent. For two, attempts at such integration
quickly become insurmountably complex. Logging integration between
Maven and a pluging declaring its own slf4j dependencies is not needed
and certainly not worth the effort.
If unconvinced, I suggest we study concrete examples.
--
Ceki
65% of statistics are made up on the spot
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Mark Struberg <st...@yahoo.de>.
Hi Ceki, thanks for the reply!
>The method signatures of classes in the org.slf4j package such as
>Logger, LoggerFactory, Marker, MDC, etc. are the same since 2005.
No they are not. I did a diff between 1.2 and the latest and it seems a few trace() methods got added. This is only a minor problem but still. This change is perfectly backward compatible, but it's not forward compatible. If there is any new signature added/changed in a newer version which we will not yet use, then we would just crash if a plugin uses the newer version. Now this is highly unlikely. But I've seen this with commons logging and I've seen this with the LocationAwareLoger as you already mentioned below. This is btw exactly the reason why we shade in all commons-* stuff to private packages...
> this means that the minor version of the SLF4J binding
> must match that of the slf4j-api. The "maintenance"
> number is unimportant.
That's perfectly fine that way! Please understand that this is nothing against slf4j! I just like to avoid that we introduce build problems to existing projects. As highlighted in my previous post there ARE ways to do that (by shielding via ClassWorlds), but this is not in place in trunk yet. Also there are zero integration tests for it atm!
>> ad 1.) maven provides slf4j-api-1.6 but a plugin uses slf4j-api-1.5,
>> 1.4, etc This might cause class cast exceptions ("Cannot cast class
>> Logger to class Logger") by having different versions of the slf4j-api
>> classes in different ClassLoaders
>
>This problem is independent of the version of the slf4j-api
>used. According to Section 4.3.4 of the Java Language Specification,
>two classes loaded by different class loaders are considered distinct
>and hence incompatible.
Maven uses a child-first classloading strategy (with exceptions) - a plugin would only see exactly 1 version. Currently (again: there is atm no shielding in place yet) if a plugin would would provide it's own slf4j-api-1.4.2 then the plugin would get this version of the Class. And if the plugin would invoke LoggerFactory.getLogger(this.class()) then what would happen? Most probably a classcast exception, right? There is a minor chance that we do not blow up as there is a complex ClassLoading environment in place. But we only know after we have some IT in place which do not exist yet. All the change got committed without a single IT, thus my -1 in the first place.
>> 2.) if you use slf4j, then ALL the funnels and logging backends must
>> have the very same version number than the slf4j-api. Otherwise you
>> are pretty much doomed. Ceki, is this correct as well?
>
>I would not go as far as "doomed". For example, the following
>combination will work fine: slf4j-api-1.7.2.jar,
>sfl4j-simple-1.6.5.jar, log4j-over-slf4j-1.6.2.jar,
>jcl-ocer-slf4j-1.7.1.jar and jul-to-slf4j-1.6.0.jar. In other words,
>you can freely mix artifacts in the 1.6.x and 1.7.x families.
But can you freely mix 1.5.x and 1.6.x? or 1.7 and 1.5 or 1.4? No you cannot as far as I've seen. So we cannot make a general assumption on that! The only safe rule is to not mix slf4j parts with diverging major or minor number. Is this correct?
>Sounds good. I would recommend isolation regardless of the version of
>the discovered slf4j dependency. The plugin author probably wishes
>logging isolation. Maven should let the plugin have its own separate
>logging environment distinct from Maven's own logging.
But that would actually be a big step backwards imo.
Currently any plugin is forced to 'funnel' the output into the logger it obtains via getLogger() itself. This is an instance of org.apache.maven.plugin.logging.Log and we have it perfectly under our own control. It's not a perfectly convenient logging api but it works and shields us from all implementation details!
If we would isolate away all the logging of a plugin (because it contains a diverging slf4j version)
then we would loose all this logs, right?
It is perfectly valid for any plugin to use slf4j right now. All it needs to do is to funnel it into our own maven logging api. We could e.g. provide a slf4j-maven-logging backend so users could use it even more easily.
LieGrue,
strub
----- Original Message -----
> From: ceki <ce...@qos.ch>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Wednesday, October 10, 2012 6:01 PM
> Subject: Re: SLF4J integration
>
> On 10.10.2012 15:42, Mark Struberg wrote:
>
> Hi Mark,
>
>> Hi!
>
>> Here are a few basic observations about slf4j. slf4j really rocks for
>> end user applications, but when it comes to deep container core stuff
>> you must take care about classloader clashes much more than within an
>> end-user project. We just don't know what a user defined in his
>> <plugin> sections...
>>
>> If we like to use slf4j as maven logging api and export it in the core
>> classloader then we might probably face the following problematic
>> spots
>>
>> 1.) slf4j-api <=1.5 and >=1.6 are not fully binary compatible
>> afaik. Ceki, is this correct? Afair there have been a few minor
>> changes between those versions. They do not always cause problems but
>> I've seen those in the wild already.
>
> The method signatures of classes in the org.slf4j package such as
> Logger, LoggerFactory, Marker, MDC, etc. are the same since 2005.
> Client code which only imports the Logger, LoggerFactory, Marker, MDC
> classes will run fine with any version of slf4j-api, 1.0.x onwards.
>
> SLF4J bindings such as slf4j-simple, slf4j-log4j etc import classes
> from the org.slf4j.spi and org.slf4j.helpers packages which offer
> lesser guarantees with respect to stability of method signatures. For
> instance, as you mentioned, a method signature in the
> org.slf4j.spi.LocationAwareLogger class changed between 1.5 and
> 1.6. Assuming a "major.minor.maintenance" versioning scheme, this
> means that the minor version of the SLF4J binding must match that of
> the slf4j-api. The "maintenance" number is unimportant.
>
> As a client only importing from the org.slf4j package, you don't have
> to worry about the version of the slf4j-api with which some other
> dependency was compiled with.
>
>> 2.) if you use slf4j, then ALL the funnels and logging backends must
>> have the very same version number than the slf4j-api. Otherwise you
>> are pretty much doomed. Ceki, is this correct as well?
>
> I would not go as far as "doomed". For example, the following
> combination will work fine: slf4j-api-1.7.2.jar,
> sfl4j-simple-1.6.5.jar, log4j-over-slf4j-1.6.2.jar,
> jcl-ocer-slf4j-1.7.1.jar and jul-to-slf4j-1.6.0.jar. In other words,
> you can freely mix artifacts in the 1.6.x and 1.7.x families.
>
>> 3.) if we would provide a sfl4j funnel (e.g. log4j-over-slf4j) and a
>> plugin brings his own log4j.jar then we will have class path clashes
>> as well.
>
> There is no need for Maven to provide slf4j bridges (or funnels as you
> say) to plugins, is there?
>
>> I'm happy if someone tells me the above observations are wrong and I
>> just failed to setup the stuff properly. If not, then we still can use
>> slf4j for maven BUT we need to isolate it really well via
>> classworlds. And of course that would mean that we miss maven logging
>> for those 'isolated' plugins, right?
>
> Most plugins should be able to see org.slf4j.* classes exported by
> maven-core. For the rare few plug-ins which declare their own version
> of slf4j artifacts, isolating the org.slf4j.* classes makes
> sense. Such isolation would serve two purposes. 1) it would avoid any
> version mismatch problem 2) it would isolate the plugin's logging from
> the logging in Maven core probably as intended by the plugin author.
>
>> I'll first sum up the problems which will occur if the upper
>> assumptions are correct.
>
>> ad 1.) maven provides slf4j-api-1.6 but a plugin uses slf4j-api-1.5,
>> 1.4, etc This might cause class cast exceptions ("Cannot cast class
>> Logger to class Logger") by having different versions of the slf4j-api
>> classes in different ClassLoaders
>
> This problem is independent of the version of the slf4j-api
> used. According to Section 4.3.4 of the Java Language Specification,
> two classes loaded by different class loaders are considered distinct
> and hence incompatible.
>
>> ad 2.) we provide slf4j-simple-1.6 and user provides
>> slf4j-xxx-1.4. This will most probably end up in a big *boom*. And we
>> do not know all slf4j-** as any user might easily add his own backend.
>
> If I understand correctly, by default maven uses a "self-first" class
> loading strategy. Plugin's class loader will load slf4j classes
> defined in the plugin and everything may/should work seamlessly for
> legacy plugins. For non legacy plugins requesting slf4j logger
> injection via annotations and simultaneously declaring dependencies to
> slf4j classes, class cast exceptions are likely to be thrown.
>
>> ad 3.) We will face class path clashes since a few slf4j funnels are
>> not fully binary compatible with the original impls. So funneling is
>> hard to do in maven. If others think it is possible, then please point
>> out a way to do this properly, thanks!
>
> As mentioned earlier, I don't think Maven should use, declare or
> export any slf4j bridges.
>
>> Now for the workaround we could implement:
>>
>
>> While discussing this topic with Stephen he had the idea to scan
>> whether a plugin uses slf4j by unzipping all plugin dependencies and
>> do some checks. E.g. check whether there is a
>> org.slf4j.impl.StaticLoggerBinder.class If we detect this or any slf4j
>> with a version != the version used in maven-core, then we must isolate
>> away slf4j provided by the maven core via ClassWorlds.
>
> Sounds good. I would recommend isolation regardless of the version of
> the discovered slf4j dependency. The plugin author probably wishes
> logging isolation. Maven should let the plugin have its own separate
> logging environment distinct from Maven's own logging.
>
> I hope you find the above helpful.
>
> -- Ceki
> 65% of statistics are made up on the spot
>
> ---------------------------------------------------------------------
> 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: SLF4J integration
Posted by ceki <ce...@qos.ch>.
On 10.10.2012 15:42, Mark Struberg wrote:
Hi Mark,
> Hi!
> Here are a few basic observations about slf4j. slf4j really rocks for
> end user applications, but when it comes to deep container core stuff
> you must take care about classloader clashes much more than within an
> end-user project. We just don't know what a user defined in his
> <plugin> sections...
>
> If we like to use slf4j as maven logging api and export it in the core
> classloader then we might probably face the following problematic
> spots
>
> 1.) slf4j-api <=1.5 and >=1.6 are not fully binary compatible
> afaik. Ceki, is this correct? Afair there have been a few minor
> changes between those versions. They do not always cause problems but
> I've seen those in the wild already.
The method signatures of classes in the org.slf4j package such as
Logger, LoggerFactory, Marker, MDC, etc. are the same since 2005.
Client code which only imports the Logger, LoggerFactory, Marker, MDC
classes will run fine with any version of slf4j-api, 1.0.x onwards.
SLF4J bindings such as slf4j-simple, slf4j-log4j etc import classes
from the org.slf4j.spi and org.slf4j.helpers packages which offer
lesser guarantees with respect to stability of method signatures. For
instance, as you mentioned, a method signature in the
org.slf4j.spi.LocationAwareLogger class changed between 1.5 and
1.6. Assuming a "major.minor.maintenance" versioning scheme, this
means that the minor version of the SLF4J binding must match that of
the slf4j-api. The "maintenance" number is unimportant.
As a client only importing from the org.slf4j package, you don't have
to worry about the version of the slf4j-api with which some other
dependency was compiled with.
> 2.) if you use slf4j, then ALL the funnels and logging backends must
> have the very same version number than the slf4j-api. Otherwise you
> are pretty much doomed. Ceki, is this correct as well?
I would not go as far as "doomed". For example, the following
combination will work fine: slf4j-api-1.7.2.jar,
sfl4j-simple-1.6.5.jar, log4j-over-slf4j-1.6.2.jar,
jcl-ocer-slf4j-1.7.1.jar and jul-to-slf4j-1.6.0.jar. In other words,
you can freely mix artifacts in the 1.6.x and 1.7.x families.
> 3.) if we would provide a sfl4j funnel (e.g. log4j-over-slf4j) and a
> plugin brings his own log4j.jar then we will have class path clashes
> as well.
There is no need for Maven to provide slf4j bridges (or funnels as you
say) to plugins, is there?
> I'm happy if someone tells me the above observations are wrong and I
> just failed to setup the stuff properly. If not, then we still can use
> slf4j for maven BUT we need to isolate it really well via
> classworlds. And of course that would mean that we miss maven logging
> for those 'isolated' plugins, right?
Most plugins should be able to see org.slf4j.* classes exported by
maven-core. For the rare few plug-ins which declare their own version
of slf4j artifacts, isolating the org.slf4j.* classes makes
sense. Such isolation would serve two purposes. 1) it would avoid any
version mismatch problem 2) it would isolate the plugin's logging from
the logging in Maven core probably as intended by the plugin author.
> I'll first sum up the problems which will occur if the upper
> assumptions are correct.
> ad 1.) maven provides slf4j-api-1.6 but a plugin uses slf4j-api-1.5,
> 1.4, etc This might cause class cast exceptions ("Cannot cast class
> Logger to class Logger") by having different versions of the slf4j-api
> classes in different ClassLoaders
This problem is independent of the version of the slf4j-api
used. According to Section 4.3.4 of the Java Language Specification,
two classes loaded by different class loaders are considered distinct
and hence incompatible.
> ad 2.) we provide slf4j-simple-1.6 and user provides
> slf4j-xxx-1.4. This will most probably end up in a big *boom*. And we
> do not know all slf4j-** as any user might easily add his own backend.
If I understand correctly, by default maven uses a "self-first" class
loading strategy. Plugin's class loader will load slf4j classes
defined in the plugin and everything may/should work seamlessly for
legacy plugins. For non legacy plugins requesting slf4j logger
injection via annotations and simultaneously declaring dependencies to
slf4j classes, class cast exceptions are likely to be thrown.
> ad 3.) We will face class path clashes since a few slf4j funnels are
> not fully binary compatible with the original impls. So funneling is
> hard to do in maven. If others think it is possible, then please point
> out a way to do this properly, thanks!
As mentioned earlier, I don't think Maven should use, declare or
export any slf4j bridges.
> Now for the workaround we could implement:
>
> While discussing this topic with Stephen he had the idea to scan
> whether a plugin uses slf4j by unzipping all plugin dependencies and
> do some checks. E.g. check whether there is a
> org.slf4j.impl.StaticLoggerBinder.class If we detect this or any slf4j
> with a version != the version used in maven-core, then we must isolate
> away slf4j provided by the maven core via ClassWorlds.
Sounds good. I would recommend isolation regardless of the version of
the discovered slf4j dependency. The plugin author probably wishes
logging isolation. Maven should let the plugin have its own separate
logging environment distinct from Maven's own logging.
I hope you find the above helpful.
--
Ceki
65% of statistics are made up on the spot
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: SLF4J integration
Posted by Mark Struberg <st...@yahoo.de>.
Hi!
Here are a few basic observations about slf4j.
slf4j really rocks for end user applications, but when it comes to deep container core stuff you must take care about classloader clashes much more than within an end-user project. We just don't know what a user defined in his <plugin> sections…
If we like to use slf4j as maven logging api and export it in the core classloader then we might probably face the following problematic spots
1.) slf4j-api <=1.5 and >=1.6 are not fully binary compatible afaik. Ceki, is this correct? Afair there have been a few minor changes between those versions. They do not always cause problems but I've seen those in the wild already.
2.) if you use slf4j, then ALL the funnels and logging backends must have the very same version number than the slf4j-api. Otherwise you are pretty much doomed. Ceki, is this correct as well?
3.) if we would provide a sfl4j funnel (e.g. log4j-over-slf4j) and a plugin brings his own log4j.jar then we will have class path clashes as well.
I'm happy if someone tells me the above observations are wrong and I just failed to setup the stuff properly. If not, then we still can use slf4j for maven BUT we need to isolate it really well via classworlds. And of course that would mean that we miss maven logging for those 'isolated' plugins, right?
I'll first sum up the problems which will occur if the upper assumptions are correct.
ad 1.) maven provides slf4j-api-1.6 but a plugin uses slf4j-api-1.5, 1.4, etc
This might cause class cast exceptions ("Cannot cast class Logger to class Logger") by having different versions of the slf4j-api classes in different ClassLoaders
ad 2.) we provide slf4j-simple-1.6 and user provides slf4j-xxx-1.4. This will most probably end up in a big *boom*. And we do not know all slf4j-** as any user might easily add his own backend.
ad 3.) We will face class path clashes since a few slf4j funnels are not fully binary compatible with the original impls. So funneling is hard to do in maven. If others think it is possible, then please point out a way to do this properly, thanks!
Now for the workaround we could implement:
While discussing this topic with Stephen he had the idea to scan whether a plugin uses slf4j by unzipping all plugin dependencies and do some checks. E.g. check whether there is a org.slf4j.impl.StaticLoggerBinder.class
If we detect this or any slf4j with a version != the version used in maven-core, then we must isolate away slf4j provided by the maven core via ClassWorlds.
I'm happy about any feedback!
LieGrue,
strub
----- Original Message -----
> From: Jason van Zyl <ja...@tesla.io>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Saturday, October 6, 2012 9:31 PM
> Subject: SLF4J integration
>
>T he commit for review if anyone wants to take a look is here:
>
> https://github.com/tesla/maven-3/commit/4595e0860243854a7d80db8ebea97205aa4aca65
>
> Ceki added support for logging to a file without massive contortions so I have
> defaulted the implementation to slf4j-simple which is small and provides the
> equivalent functionality to the previous setup. It can also be controlled by a
> simple configuration file. Everything is working but I would like to try and
> make one small change as currently in debug mode (-X) all the binding
> information that Sisu knows about is pushed to the console which is very
> distracting. I think this is more trace level information. Once that is resolved
> and I write the documentation about how the new logging system works and how
> the implementations can be swapped I'll dcommit to Apache.
>
> Then I'll add the tests and documentation for the JSR330 work. After that
> I'll look at the Aether integration. Hope to have this done over the
> weekend.
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> The modern conservative is engaged in one of man's oldest exercises in moral
> philosophy; that is,
> the search for a superior moral justification for selfishness.
>
> -- John Kenneth Galbraith
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org