Return-Path: 
 <users-return-135413-apmail-maven-users-archive=maven.apache.org@maven.apache.org>
X-Original-To: apmail-maven-users-archive@www.apache.org
Delivered-To: apmail-maven-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 6908010889
	for <apmail-maven-users-archive@www.apache.org>;
 Wed, 12 Feb 2014 01:22:33 +0000 (UTC)
Received: (qmail 3775 invoked by uid 500); 12 Feb 2014 01:22:25 -0000
Delivered-To: apmail-maven-users-archive@maven.apache.org
Received: (qmail 3672 invoked by uid 500); 12 Feb 2014 01:22:24 -0000
Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:users-unsubscribe@maven.apache.org>
List-Help: <mailto:users-help@maven.apache.org>
List-Post: <mailto:users@maven.apache.org>
List-Id: "Maven Users List" <users.maven.apache.org>
Reply-To: "Maven Users List" <users@maven.apache.org>
Delivered-To: mailing list users@maven.apache.org
Received: (qmail 3661 invoked by uid 99); 12 Feb 2014 01:22:24 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Feb 2014 01:22:24 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of ljnelson@gmail.com designates
 209.85.216.176 as permitted sender)
Received: from [209.85.216.176] (HELO mail-qc0-f176.google.com)
 (209.85.216.176)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Feb 2014 01:22:18 +0000
Received: by mail-qc0-f176.google.com with SMTP id e16so14363875qcx.35
        for <users@maven.apache.org>; Tue, 11 Feb 2014 17:21:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=mR8hvYq/mN6SnVu6wgTrCFS62xbtx74jdXhaa3q0KV4=;
        b=KNeTyxbU+2uMBiES7aH/MFgqeVffXu7pli2efgCqKBBA/XJazimpLryEDqej5DumQ2
         IiT6BhMBjBVdSpy8n6LEXkrMY+e4hdAS36KO0HTR514h6yVGv8byLlTCE5mNmV1D94Wn
         sJQxroKOoZf7UwD1QjIoNZWCMvJIznKSxerQKFfNu9Ubo+3oJgRHhgtX81O95FQRuj7s
         V1g105kkcuy/ymxhx7lmpMXnCoZqBUFn1CihvxCFDYl+knT2jYol4q761ObyROMip3up
         vsGKkd0Bl/Z21zPRjpbnoXxvThVpABmHJwLwtV5/F082ZLQqX6XQLIXQnmmfpkci3Mwk
         XNRw==
MIME-Version: 1.0
X-Received: by 10.224.115.143 with SMTP id i15mr11383055qaq.57.1392168117748;
 Tue, 11 Feb 2014 17:21:57 -0800 (PST)
Received: by 10.96.61.9 with HTTP; Tue, 11 Feb 2014 17:21:57 -0800 (PST)
In-Reply-To: 
 <CADVp3v9wpqkQRA5UyYMTCj6cmN3n-y4G85zgcQ8sOeZewKhnsg@mail.gmail.com>
References: <1392106732883-5784035.post@n5.nabble.com>
	<CAHNdxun4zRCm1mCpnA_q27OYJj0khLpKLpBsGCD0Es4DRn3Qaw@mail.gmail.com>
	<CADVp3v9wpqkQRA5UyYMTCj6cmN3n-y4G85zgcQ8sOeZewKhnsg@mail.gmail.com>
Date: Tue, 11 Feb 2014 17:21:57 -0800
Message-ID: 
 <CAHNdxukgfWP4Rrthk2uMegQU6zToYxMHAvvC1KfAS5J7RqGQtg@mail.gmail.com>
Subject: Re: Adding dependency management to parent pom causes errors
From: Laird Nelson <ljnelson@gmail.com>
To: Maven Users List <users@maven.apache.org>
Content-Type: multipart/alternative; boundary=047d7bf0ec5c20495004f22b66e4
X-Virus-Checked: Checked by ClamAV on apache.org

--047d7bf0ec5c20495004f22b66e4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 11, 2014 at 4:48 PM, Barrie Treloar <baerrach@gmail.com> wrote:

> This is also best practice.
>

Agreed wholesale.  I think the original poster was wondering why this
stanza:

<dependencies>
<!-- ... -->
</dependencies>


...when "wrapped" (replaced, really) thusly:

*<dependencyManagement>*
  <dependencies>
  <!-- ... -->
  </dependencies>
*</dependencyManagement>*


...suddenly {handwave handwave} made his dependencies stop {handwave}
resolving.  (The answer being of course that there is no longer a
<dependencies> section in this particular case; he replaced it=E2=80=94did =
not
augment it=E2=80=94with a <dependencyManagement> stanza.)

While we're on the subject of best practices in this area, we've also found
that dependency managing the versions of even child <modules> pays off in
the end.

Best,
Laird

--=20
http://about.me/lairdnelson

--047d7bf0ec5c20495004f22b66e4--