Ok, thanks. I'm working on a library in my spare time and hadn't
thought about this before and this diagram made me think about it.
On 2011-08-11 16:27, Ceki Gülcü wrote:
Hi Rusty,
Letting the end user choose the underlying logging framework is the
reason SLF4J exists in the first place. I
I definitely like http://slf4j.org/images/concrete-bindings.png
Straightforward and clear.
On 2011-08-12 12:32, Ceki Gülcü wrote:
I've taken yet another crack at this:
http://slf4j.org/images/concrete-bindings.odg
http://slf4j.org/images/concrete-bindings.png
http://slf4j.org/images/legacy.od
Just a stab in the dark here, but have you tried using a "provided"
scope? That keeps it from being added to your war, or whatever, and
says that it will be provided by the runtime environment.
commons-logging
commons-logging
1.1.1
provided
commons-logging
commons-logging-api
1.
Hi Douglas
I'm not sure but I suspect that
jar
might be the root of your problem. Just delete that line and try it again.
Beside that, I can only guarantee that exclusion is working as expected in
Maven 3.0.3 in combination with dependencyManagement in a parent pom.
So the following is working
Jar is default type, so leaving it out vs. putting it in is just a matter of
being explicit or not.
Douglas
On Aug 13, 2011, at 2:34 PM, Joern Huxhorn wrote:
> Hi Douglas
>
> I'm not sure but I suspect that
> jar
> might be the root of your problem. Just delete that line and try it again.
>
>
Now someone needs to take a decision!!11!!
:-)
On 08/13/2011 10:51 AM, Rusty Wright wrote:
I definitely like http://slf4j.org/images/concrete-bindings.png
Straightforward and clear.
On 2011-08-12 12:32, Ceki Gülcü wrote:
I've taken yet another crack at this:
http://slf4j.org/images/concrete
