axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <>
Subject Re: [jira] Commented: (AXIS2-4334) Cannot turn off stdout messages when using WSDL 2.0
Date Fri, 16 Oct 2009 09:55:15 GMT

Andreas Veithen wrote:

> Looking at the Apache WS universe alone:
> - Woden depends on slf4j-log4j12
> - Rampart directly depends on slf4j-jdk14 and transitively (via
> opensaml2) on jcl-over-slf4j and log4j-over-slf4j.

Woden includes slf4j-log4j12 in the runtime scope, excludes log4j and
then includes it a few lines below. This indicates that the author did
not know about maven proximity rules. The exclusion declaration within
the slf4j-log4j12 dependency declaration is unnecessary as a local
declaration trumps dependency declarations made upstream. Although
this might not be true for dependencies in the runtime scope, in which
case you can strike my comment about the author not knowing proximity
rules. Anyway, I think the log4j dependency should have been made in
the test scope and not runtime.

As you say rampart declares a compile (default) dependency on
slf4j-jdk14 and a test time dependency on log4j.

IMHO, dependencies on slf4j bindings should be in the test scope.

> These are the two projects in Apache WS that I know are using SLF4J
> and both include unnecessary dependencies on bindings/bridges.
> BTW, it doesn't surprise me to see dependencies on slf4j bindings. The
> reason is quite simple: everybody wants to make his own project as
> easy to use as possible. If a project X doesn't declare any
> dependencies on an slf4j binding, then the user has to declare another
> dependency to make library X work. If the user doesn't know SLF4J or
> didn't read project X's documentation, he might blame X. On the other
> hand, if X declares a dependency on a binding that causes a conflict
> with project Y, then the user has no reason to blame either X or Y in
> particular.

Interesting perspective. Any responsible developer can see that declaring a 
dependency on an slf4j-binding in a scope other than test has undesirable 
consequences downstream. If asked properly, I would assume that they would 
kindly oblige.

> There is really no contradiction here. From an architectural point of
> view, I like the approach, but from a dependency management
> perspective, it is not as nice as I would like. Interestingly most of
> the issues point to a missing feature in Maven, namely virtual
> dependencies (which would work in a similar way as virtual packages in
> Debian's package management system). There is a similar problem with
> the Java Activation Framework and JavaMail: there are two
> implementations of these APIs, one from Sun and one from Geronimo.
> There is no way (other than using explicit exclusions) to tell Maven
> that these are substitutes of each other and that it if both appear as
> transitive dependencies it would be sufficient to retain one of them
> to satisfy the dependencies of the project.
> Did you ever think about trying to convince the Maven people to
> implement such a feature?

There have been request in this direction but if I remember correctly they have 
been met with some resistance from the maven folks.

Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.

View raw message