Return-Path: X-Original-To: apmail-tomee-commits-archive@www.apache.org Delivered-To: apmail-tomee-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 39205105B0 for ; Tue, 20 Aug 2013 14:58:58 +0000 (UTC) Received: (qmail 53160 invoked by uid 500); 20 Aug 2013 14:58:57 -0000 Delivered-To: apmail-tomee-commits-archive@tomee.apache.org Received: (qmail 52533 invoked by uid 500); 20 Aug 2013 14:58:55 -0000 Mailing-List: contact commits-help@tomee.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@tomee.apache.org Delivered-To: mailing list commits@tomee.apache.org Received: (qmail 52451 invoked by uid 500); 20 Aug 2013 14:58:53 -0000 Delivered-To: apmail-openejb-commits@openejb.apache.org Received: (qmail 52406 invoked by uid 99); 20 Aug 2013 14:58:53 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Aug 2013 14:58:53 +0000 Date: Tue, 20 Aug 2013 14:58:53 +0000 (UTC) From: "Jens Bannmann (JIRA)" To: commits@openejb.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (OPENEJB-2036) openejb-core has conflicting dependencies to commons-pool MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/OPENEJB-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13745030#comment-13745030 ] Jens Bannmann commented on OPENEJB-2036: ---------------------------------------- I think with forcing a different version of commons-pool onto other libraries which were not compiled against that version, you risk runtime errors - unless, of course, you do this only for patch releases (x.x.N) of projects that use strict semantic versioning, and thus never change their API for patch releases. For the record: In our project, we activated this rule after we had the following incident: Our project uses libraries UTIL and FOO, and FOO also uses UTIL. We updated our project to a newer version of UTIL, but failed to notice that the version of "foo" still relied on the old "util". Maven simply resolved the conflict to the newer UTIL version, so that version got packaged. However, the FOO version would not even compile against the new UTIL version, so we got a NoSuchMethodError at runtime. The dependency convergence rule prevents such problems by failing the build. > openejb-core has conflicting dependencies to commons-pool > --------------------------------------------------------- > > Key: OPENEJB-2036 > URL: https://issues.apache.org/jira/browse/OPENEJB-2036 > Project: OpenEJB > Issue Type: Bug > Affects Versions: 4.5.1 > Reporter: Jens Bannmann > Priority: Minor > > I activated the Maven Enforcer dependency convergence rule (see [http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html]) for my project, and got an error caused by openejb: > [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce) @ myartifact --- > > [WARNING] > Dependency convergence error for commons-pool:commons-pool:1.5.4 paths to dependency are: > +-mygroup:myartifact:1.0-SNAPSHOT > +-org.apache.openejb:openejb-core:4.5.1 > +-commons-dbcp:commons-dbcp:1.4 > +-commons-pool:commons-pool:1.5.4 > and > +-mygroup:myartifact:1.0-SNAPSHOT > +-org.apache.openejb:openejb-core:4.5.1 > +-commons-pool:commons-pool:1.5.7 > In my opinion, openejb-core has to either > a) use a version of commons-dbcp that uses the same version of commons-pool (1.5.7), or > b) exclude the transitive dependency to 1.5.4. > Besides ensuring correctness within OpenEJB, this has the added benefit of not breaking downstream builds which use this rule from Maven Enforcer Plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira