Changing the slf4j implementation in m2 plugin

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Changing the slf4j implementation in m2 plugin

mihobson
Hi there,

I want to change the slf4j implementation used by jetty6 in the m2
plugin.  The plugin pom brings in the slf4j-simple dependency, which I
ideally wish to exclude and use the slf4j-log4j12 implementation
instead.

I know I can introduce further dependencies for jetty6 in the
plugin/dependencies section of my pom, although there appears no way
to exclude existing ones.  Also, I can't find any documentation on
what is supposed to happen if multiple slf4j implementations exist in
the classpath, but I'd assume it's a first-come first-serve basis; so
slf4j-simple always gets precedence over slf4j-log4j12.

One solution would be to remove slf4j-simple from the jetty pom and
allow the user to configure this explicity, although this would
involve an extra step for newcomers.  Any ideas?

Cheers,

Mark


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Changing the slf4j implementation in m2 plugin

Ceki Gulcu-2

Mark,

Does Maven provide an exclusion mechanism? Depending on the perspective,
the problem you describe seems to be related as much a Jetty as to Maven.

As for your question about multiple slf4j jar files, the behavior is
undefined, exactly in the same way as if you had multiple copies of a given
library on the class path.

HTH,
At 11:31 AM 3/20/2006, Mark Hobson wrote:

>Hi there,
>
>I want to change the slf4j implementation used by jetty6 in the m2
>plugin.  The plugin pom brings in the slf4j-simple dependency, which I
>ideally wish to exclude and use the slf4j-log4j12 implementation
>instead.
>
>I know I can introduce further dependencies for jetty6 in the
>plugin/dependencies section of my pom, although there appears no way
>to exclude existing ones.  Also, I can't find any documentation on
>what is supposed to happen if multiple slf4j implementations exist in
>the classpath, but I'd assume it's a first-come first-serve basis; so
>slf4j-simple always gets precedence over slf4j-log4j12.
>
>One solution would be to remove slf4j-simple from the jetty pom and
>allow the user to configure this explicity, although this would
>involve an extra step for newcomers.  Any ideas?
>
>Cheers,
>
>Mark

--
Ceki Gülcü
http://ceki.blogspot.com/



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Changing the slf4j implementation in m2 plugin

mihobson
Hi Ceki,

Thanks for the reply.

On 20/03/06, Ceki Gülcü <[hidden email]> wrote:
> Does Maven provide an exclusion mechanism? Depending on the perspective,
> the problem you describe seems to be related as much a Jetty as to Maven.

It does for regular dependencies, but I'm not aware of anything
similar for plugin dependencies.

> As for your question about multiple slf4j jar files, the behavior is
> undefined, exactly in the same way as if you had multiple copies of a given
> library on the class path.

That's what I figured.  I guess exclusion is the only way to go,
unless jetty's pom removes the slf4j implementation dependency.

Cheers,

Mark


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Changing the slf4j implementation in m2 plugin

jan_bartel
Hi Mark,

I've had a couple of gos at trying to exclude the slf4j-simple.jar from a
webapp project using the plugin, but I haven't got it to work. :-(. Probably
best if you asked the maven guys if it is possible?

In the meanwhile, I am working on the whole jasper/"jesper" issue and the
commons-logging dependency. As "jesper" does not require commons-logging,
then the plugin could, in theory, do without providing any slf4j impl at all.
However, that would mandate that users would need to use jdk1.5 (as jesper is
jsp 2.1 which requires jdk1.5). I don't think that is reasonable at this stage,
so I need to provide a way for users to specify with a <configuration> option
whether they want to use jsp2.1 or jsp2.0. If the former, then users can put
whatever logging they like on the classpath. If the latter, then I need a mechanism
to detect whether an slf4j impl is already on the classpath, and if not, provide a
default one that the plugin will downloaded at runtime (if not already in the
local repo of course).


regards
Jan

Mark Hobson wrote:

> Hi Ceki,
>
> Thanks for the reply.
>
> On 20/03/06, Ceki Gülcü <[hidden email]> wrote:
>
>>Does Maven provide an exclusion mechanism? Depending on the perspective,
>>the problem you describe seems to be related as much a Jetty as to Maven.
>
>
> It does for regular dependencies, but I'm not aware of anything
> similar for plugin dependencies.
>
>
>>As for your question about multiple slf4j jar files, the behavior is
>>undefined, exactly in the same way as if you had multiple copies of a given
>>library on the class path.
>
>
> That's what I figured.  I guess exclusion is the only way to go,
> unless jetty's pom removes the slf4j implementation dependency.
>
> Cheers,
>
> Mark
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> <a href="http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Re: Changing the slf4j implementation in m2 plugin

mihobson
Hi Jan,

On 20/03/06, Jan Bartel <[hidden email]> wrote:
> I've had a couple of gos at trying to exclude the slf4j-simple.jar from a
> webapp project using the plugin, but I haven't got it to work. :-(. Probably
> best if you asked the maven guys if it is possible?

Sure, I'll drop a mail to the maven list thanks.

> In the meanwhile, I am working on the whole jasper/"jesper" issue and the
> commons-logging dependency. As "jesper" does not require commons-logging,
> then the plugin could, in theory, do without providing any slf4j impl at all.
> However, that would mandate that users would need to use jdk1.5 (as jesper is
> jsp 2.1 which requires jdk1.5). I don't think that is reasonable at this stage,
> so I need to provide a way for users to specify with a <configuration> option
> whether they want to use jsp2.1 or jsp2.0. If the former, then users can put
> whatever logging they like on the classpath. If the latter, then I need a mechanism
> to detect whether an slf4j impl is already on the classpath, and if not, provide a
> default one that the plugin will downloaded at runtime (if not already in the
> local repo of course).

I'm not aware of "jesper" - is this some branch of jasper?  So does
jetty itself use the slf4j api directly and jcl is only required by
jasper?  In which case would jcl104-over-slf4j and slf4j-api suffice,
leaving the user to supply a slf4j impl?  Although I seem to recall
Ceki saying a plain slf4j-api jar doesn't exist as such yet.

Mark


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Changing the slf4j implementation in m2 plugin

jan_bartel
Hi Mark,

>>In the meanwhile, I am working on the whole jasper/"jesper" issue and the
>>commons-logging dependency. As "jesper" does not require commons-logging,
>>then the plugin could, in theory, do without providing any slf4j impl at all.
>>However, that would mandate that users would need to use jdk1.5 (as jesper is
>>jsp 2.1 which requires jdk1.5). I don't think that is reasonable at this stage,
>>so I need to provide a way for users to specify with a <configuration> option
>>whether they want to use jsp2.1 or jsp2.0. If the former, then users can put
>>whatever logging they like on the classpath. If the latter, then I need a mechanism
>>to detect whether an slf4j impl is already on the classpath, and if not, provide a
>>default one that the plugin will downloaded at runtime (if not already in the
>>local repo of course).
>
>
> I'm not aware of "jesper" - is this some branch of jasper?  
There's a thread on jetty-discuss with subject "Jasper JSP for Jetty6!".
It's not a branch as such. We just check out Jasper and apply some patches
to it to remove the commons-logging. We'll be shipping that with jetty6 and
it requires jdk1.5 as it is for jsp2.1.  We'll also ship the current
version of Jasper that commons-logging in it for jsp2.0. The start.jar
mechanism (for standalone jetty) will work out which jdk you are using
and automatically put the right version of jasper on the classpath for
you.


> So does
> jetty itself use the slf4j api directly and jcl is only required by
> jasper?  In which case would jcl104-over-slf4j and slf4j-api suffice,
> leaving the user to supply a slf4j impl?  Although I seem to recall
> Ceki saying a plain slf4j-api jar doesn't exist as such yet.
Jetty itself has no dependency on any log infrastructure other than its
own (see org.mortbay.log.Log). The jetty log implementation decides at
runtime whether to delegate to the slf4j interface if it can find an slf4j
impl on the classpath, or failing that, to do its own logging.  Jasper is
the only thing with a dependency on a logging infrastructure.

As for leaving the user to select a log implementation for the plugin, I'd
much rather have it work straight out of the box, but allow the user to
configure a different slf4j logging delegate if they want.

cheers
Jan

>
> Mark
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> <a href="http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Re: Changing the slf4j implementation in m2 plugin

mihobson
Hi Jan

On 20/03/06, Jan Bartel <[hidden email]> wrote:

> There's a thread on jetty-discuss with subject "Jasper JSP for Jetty6!".
> It's not a branch as such. We just check out Jasper and apply some patches
> to it to remove the commons-logging. We'll be shipping that with jetty6 and
> it requires jdk1.5 as it is for jsp2.1.  We'll also ship the current
> version of Jasper that commons-logging in it for jsp2.0. The start.jar
> mechanism (for standalone jetty) will work out which jdk you are using
> and automatically put the right version of jasper on the classpath for
> you.
>
> Jetty itself has no dependency on any log infrastructure other than its
> own (see org.mortbay.log.Log). The jetty log implementation decides at
> runtime whether to delegate to the slf4j interface if it can find an slf4j
> impl on the classpath, or failing that, to do its own logging.  Jasper is
> the only thing with a dependency on a logging infrastructure.

Thanks for the clarification.  Would it not be easier to allow jasper
to continue to use jcl and then leave jcl104-over-slf4j to bridge to
slf4j?

> As for leaving the user to select a log implementation for the plugin, I'd
> much rather have it work straight out of the box, but allow the user to
> configure a different slf4j logging delegate if they want.

I agree that would be best.  I've raised the following m2 issue to
allow dependencies to be excluded from plugins:

http://jira.codehaus.org/browse/MNG-2163

Cheers,

Mark


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Re: Changing the slf4j implementation in m2 plugin

Ceki Gulcu-2
In reply to this post by jan_bartel
At 12:26 AM 3/21/2006, Jan Bartel wrote:

>As for leaving the user to select a log implementation for the plugin, I'd
>much rather have it work straight out of the box, but allow the user to
>configure a different slf4j logging delegate if they want.

+1

How do we go from a wish to actually making it happen? Apache Directory
project faces a similar situation and probably many other projects as well.

>cheers
>Jan

--
Ceki Gülcü
http://ceki.blogspot.com/



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Changing the slf4j implementation in m2 plugin

jan_bartel
Hi Ceki,

I'm 90% of the way there with the jetty maven plugin. At runtime, I
check the classpath for commons-logging and then slf4j classes.
If a user has put commons-logging on to the classpath of the plugin
(eg via a plugin dependency or via a project dependency) then I
remove the jcl-over-slf4j and the slf4j-simple jars from the
plugin's classpath as the user is control of their logging. If I
can't find a commons-logging impl, I check for an slf4j impl. Again,
if the user has specified an impl, I get rid of the default slf4j-simple
jar from the classpath. If the user hasn't specified any logging, then
I use the defaults of jcl-over-slf4j and slf4j-simple.

In order to change the classpath of the plugin, I have had to
introduce another URLClassloader as the child of the maven plugin runtime
classloader. The problem is that the maven classworld classloader
is misbehaving and doesn't delegate correctly on resolution calls
from the child. I think this is a known problem and will probably be
fixed in the next version of maven. However, in the meanwhile
I am doing some workarounds. I've got a little way to go with the
workarounds, but I think it will be able to be done.

cheers
Jan

Ceki Gülcü wrote:

> At 12:26 AM 3/21/2006, Jan Bartel wrote:
>
>> As for leaving the user to select a log implementation for the plugin,
>> I'd
>> much rather have it work straight out of the box, but allow the user to
>> configure a different slf4j logging delegate if they want.
>
>
> +1
>
> How do we go from a wish to actually making it happen? Apache Directory
> project faces a similar situation and probably many other projects as well.
>
>> cheers
>> Jan
>
>



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Re: Changing the slf4j implementation in m2 plugin

Ceki Gulcu-2

Jan,

Thank you for the lengthy response. From what you state, it looks like you
are doing the maximum without explicit support from Maven. However,
wouldn't it be nicer if Maven itself provided ways for the user to specify
the preferred implementation of a given API? It seems like a basic
requirement to me. I'll go knock on Maven's door to see what they have to say.

At 02:13 PM 3/22/2006, Jan Bartel wrote:

>Hi Ceki,
>
>I'm 90% of the way there with the jetty maven plugin. At runtime, I
>check the classpath for commons-logging and then slf4j classes.
>If a user has put commons-logging on to the classpath of the plugin
>(eg via a plugin dependency or via a project dependency) then I
>remove the jcl-over-slf4j and the slf4j-simple jars from the plugin's
>classpath as the user is control of their logging. If I can't find a
>commons-logging impl, I check for an slf4j impl. Again,
>if the user has specified an impl, I get rid of the default slf4j-simple
>jar from the classpath. If the user hasn't specified any logging, then
>I use the defaults of jcl-over-slf4j and slf4j-simple.
>
>In order to change the classpath of the plugin, I have had to introduce
>another URLClassloader as the child of the maven plugin runtime
>classloader. The problem is that the maven classworld classloader is
>misbehaving and doesn't delegate correctly on resolution calls
>from the child. I think this is a known problem and will probably be fixed
>in the next version of maven. However, in the meanwhile
>I am doing some workarounds. I've got a little way to go with the
>workarounds, but I think it will be able to be done.
>
>cheers
>Jan
>Ceki Gülcü wrote:
>>At 12:26 AM 3/21/2006, Jan Bartel wrote:
>>
>>>As for leaving the user to select a log implementation for the plugin, I'd
>>>much rather have it work straight out of the box, but allow the user to
>>>configure a different slf4j logging delegate if they want.
>>
>>+1
>>How do we go from a wish to actually making it happen? Apache Directory
>>project faces a similar situation and probably many other projects as well.
>>
>>>cheers
>>>Jan
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Jetty-support mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/jetty-support

--
Ceki Gülcü
http://ceki.blogspot.com/



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Changing the slf4j implementation in m2 plugin

Ceki Gulcu-2
In reply to this post by mihobson

Mark,

Are you trying to embed Jetty in a larger environment or is Jetty the host
application? If Jetty is the host, then how about modifying Jetty's POM
directly? You have mentioned this possibility in your message. Have you
actually tried it?

At 11:31 AM 3/20/2006, Mark Hobson wrote:

>Hi there,
>
>I want to change the slf4j implementation used by jetty6 in the m2
>plugin.  The plugin pom brings in the slf4j-simple dependency, which I
>ideally wish to exclude and use the slf4j-log4j12 implementation
>instead.
>
>I know I can introduce further dependencies for jetty6 in the
>plugin/dependencies section of my pom, although there appears no way
>to exclude existing ones.  Also, I can't find any documentation on
>what is supposed to happen if multiple slf4j implementations exist in
>the classpath, but I'd assume it's a first-come first-serve basis; so
>slf4j-simple always gets precedence over slf4j-log4j12.
>
>One solution would be to remove slf4j-simple from the jetty pom and
>allow the user to configure this explicity, although this would
>involve an extra step for newcomers.  Any ideas?
>
>Cheers,
>
>Mark

--
Ceki Gülcü
http://ceki.blogspot.com/



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Changing the slf4j implementation in m2 plugin

mihobson
Hi Ceki,

On 22/03/06, Ceki Gülcü <[hidden email]> wrote:
> Are you trying to embed Jetty in a larger environment or is Jetty the host
> application?

I'm just using Jetty in development to run my webapp.

> If Jetty is the host, then how about modifying Jetty's POM
> directly? You have mentioned this possibility in your message. Have you
> actually tried it?

I haven't tried this, although I've no doubt that it would work.  I'm
trying to stick with official releases as much as possible to avoid
headaches!

Cheers,

Mark


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Changing the slf4j implementation in m2 plugin

jan_bartel
In reply to this post by Ceki Gulcu-2
OK. I have checked in the jetty maven plugin changes to make
commons-logging/jcl04-over-slf4j/slf4j impl configurable at
runtime.

As I said before, the plugin makes a decision at runtime which
jsp version to use based on the jdk version running the plugin.
It then takes care of the logging dependencies in jsp 2.0 jasper
if it was selected by looking for commons-logging and slf4j
impls already on the classpath and selectively removing the
transitive dependencies (jcl04-over-slf4j/simple-slf4j)
introduced by the jsp jars.

I blogged about the technique for on-the-fly transitive
resolution of poms and runtime classpath manipulation here:
http://www.mortbay.com/MB/log/janb/

regards
Jan

Ceki Gülcü wrote:

>
> Jan,
>
> Thank you for the lengthy response. From what you state, it looks like
> you are doing the maximum without explicit support from Maven. However,
> wouldn't it be nicer if Maven itself provided ways for the user to
> specify the preferred implementation of a given API? It seems like a
> basic requirement to me. I'll go knock on Maven's door to see what they
> have to say.
>
> At 02:13 PM 3/22/2006, Jan Bartel wrote:
>
>> Hi Ceki,
>>
>> I'm 90% of the way there with the jetty maven plugin. At runtime, I
>> check the classpath for commons-logging and then slf4j classes.
>> If a user has put commons-logging on to the classpath of the plugin
>> (eg via a plugin dependency or via a project dependency) then I
>> remove the jcl-over-slf4j and the slf4j-simple jars from the plugin's
>> classpath as the user is control of their logging. If I can't find a
>> commons-logging impl, I check for an slf4j impl. Again,
>> if the user has specified an impl, I get rid of the default slf4j-simple
>> jar from the classpath. If the user hasn't specified any logging, then
>> I use the defaults of jcl-over-slf4j and slf4j-simple.
>>
>> In order to change the classpath of the plugin, I have had to
>> introduce another URLClassloader as the child of the maven plugin runtime
>> classloader. The problem is that the maven classworld classloader is
>> misbehaving and doesn't delegate correctly on resolution calls
>> from the child. I think this is a known problem and will probably be
>> fixed in the next version of maven. However, in the meanwhile
>> I am doing some workarounds. I've got a little way to go with the
>> workarounds, but I think it will be able to be done.
>>
>> cheers
>> Jan
>> Ceki Gülcü wrote:
>>
>>> At 12:26 AM 3/21/2006, Jan Bartel wrote:
>>>
>>>> As for leaving the user to select a log implementation for the
>>>> plugin, I'd
>>>> much rather have it work straight out of the box, but allow the user to
>>>> configure a different slf4j logging delegate if they want.
>>>
>>>
>>> +1
>>> How do we go from a wish to actually making it happen? Apache
>>> Directory project faces a similar situation and probably many other
>>> projects as well.
>>>
>>>> cheers
>>>> Jan
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>> language
>> that extends applications into web and mobile media. Attend the live
>> webcast
>> and join the prime developer group breaking into this new coding
>> territory!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Jetty-support mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jetty-support
>
>



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support