From axis-dev-return-77027-apmail-ws-axis-dev-archive=ws.apache.org@ws.apache.org Mon Oct 19 14:18:20 2009 Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 69554 invoked from network); 19 Oct 2009 14:18:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 19 Oct 2009 14:18:19 -0000 Received: (qmail 12915 invoked by uid 500); 19 Oct 2009 14:18:19 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 12841 invoked by uid 500); 19 Oct 2009 14:18:18 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 12832 invoked by uid 99); 19 Oct 2009 14:18:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Oct 2009 14:18:18 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [85.218.33.218] (HELO mail.qos.ch) (85.218.33.218) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Oct 2009 14:18:15 +0000 Received: by mail.qos.ch (Postfix, from userid 1006) id 393562B8275; Mon, 19 Oct 2009 16:25:36 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5-gr0 (2008-06-10) on torino X-Spam-Level: Received: from [192.168.1.7] (unknown [192.168.1.7]) by mail.qos.ch (Postfix) with ESMTP id 52EDB2B8270 for ; Mon, 19 Oct 2009 16:25:31 +0200 (CEST) Message-ID: <4ADC7510.30704@qos.ch> Date: Mon, 19 Oct 2009 16:17:52 +0200 From: Ceki Gulcu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: axis-dev@ws.apache.org Subject: Re: [jira] Commented: (AXIS2-4334) Cannot turn off stdout messages when using WSDL 2.0 References: <4AD31C64.7060000@qos.ch> <4AD84303.1090003@qos.ch> <474d01b00910160549h2381c0e1v2218315ffe628d25@mail.gmail.com> In-Reply-To: <474d01b00910160549h2381c0e1v2218315ffe628d25@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Old-Spam-Status: No, score=-4.4 required=5.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5-gr0 Here is the formal definition of Maven's "proximity" rule, which is incidentally called dependency mediation: # Dependency mediation - this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the "nearest definition" which means that it will use the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, until Maven 2.0.8 it was not defined which one would win, but since Maven 2.0.9 it's the order in the declaration that counts: the first declaration wins. * "nearest definition" means that the version used will be the closest one to your project in the tree of dependencies, eg. if dependencies for A, B, and C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0 Quoted from http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html HTH, Sagara Gunathunga wrote: > On Fri, Oct 16, 2009 at 3:25 PM, Ceki Gulcu wrote: >> >> 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. > > I like to comment only about Woden. I'm not an expert in Maven > proximity but what i have experienced during several projects are > different versions of same Jar file at runtime and leads into some > version mismatch exceptions. Most of the time people find those issues > once they get a runtime exception, normally in practice we don't use > Maven dependency plug-in every time to analyze dependencies. That why > I thought to define all dependencies explicitly with exact versions > without depend on transitive dependency resolution. In case of SLF4J > those issues might be wrong but I don't want to make it as special > case . > > BTW there was recent voting thread on Woden list [1] about the > logging strategy , Most probably current strategy will change in near > future. > > [1] - http://www.nabble.com/-VOTE--Vote-for-Woden-Logging-Strategy-td25854390.html > > Thanks , > >> 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. >> http://logback.qos.ch >> > > > -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch