Return-Path: 
 <issues-return-110144-apmail-maven-issues-archive=maven.apache.org@maven.apache.org>
X-Original-To: apmail-maven-issues-archive@minotaur.apache.org
Delivered-To: apmail-maven-issues-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 991A518B2D
	for <apmail-maven-issues-archive@minotaur.apache.org>;
 Thu, 18 Feb 2016 13:28:24 +0000 (UTC)
Received: (qmail 14967 invoked by uid 500); 18 Feb 2016 13:28:18 -0000
Delivered-To: apmail-maven-issues-archive@maven.apache.org
Received: (qmail 14906 invoked by uid 500); 18 Feb 2016 13:28:18 -0000
Mailing-List: contact issues-help@maven.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@maven.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@maven.apache.org>
List-Post: <mailto:issues@maven.apache.org>
List-Id: <issues.maven.apache.org>
Reply-To: dev@maven.apache.org
Delivered-To: mailing list issues@maven.apache.org
Received: (qmail 14893 invoked by uid 99); 18 Feb 2016 13:28:18 -0000
Received: from arcas.apache.org (HELO arcas) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Feb 2016 13:28:18 +0000
Received: from arcas.apache.org (localhost [127.0.0.1])
	by arcas (Postfix) with ESMTP id 1444E2C1F5B
	for <issues@maven.apache.org>; Thu, 18 Feb 2016 13:28:18 +0000 (UTC)
Date: Thu, 18 Feb 2016 13:28:18 +0000 (UTC)
From: "Andy Wilkinson (JIRA)" <jira@apache.org>
To: issues@maven.apache.org
Message-ID: <JIRA.12935914.1454407019000.82607.1455802098080@Atlassian.JIRA>
In-Reply-To: <JIRA.12935914.1454407019000@Atlassian.JIRA>
References: <JIRA.12935914.1454407019000@Atlassian.JIRA>
 <JIRA.12935914.1454407019461@arcas>
Subject: [jira] [Commented] (MNG-5971) Imported dependencies should be
 available to inheritance processing
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/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152297#comment-15152297 ] 

Andy Wilkinson commented on MNG-5971:
-------------------------------------

{quote}
Since that scope would be processed very early (before inheritance and interpolation), you cannot use any features like property expansion.
{quote}

Given that I can do this:

{noformat}
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.example.foo</groupId>
            <artifactId>alpha</artifactId>
            <version>${foo.version}</version>
        </dependency>
        <dependency>
            <groupId>com.example.foo</groupId>
            <artifactId>bravo</artifactId>
            <version>${foo.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>           
{noformat}

I'd really like to be able to move that dependency management out into a reusable bom and do this:

{noformat}
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.example.foo</groupId>
            <artifactId>foo-bom</artifactId>
            <version>${foo.version}</version>
            <scope>include</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</dependencyManagement>
{noformat}

If the accepted goal for {{include}} is to provide a shorthand for declaring the managed dependencies directly, I'd expect that the same rules for the use of properties would apply. Is that not possible?

> Imported dependencies should be available to inheritance processing
> -------------------------------------------------------------------
>
>                 Key: MNG-5971
>                 URL: https://issues.apache.org/jira/browse/MNG-5971
>             Project: Maven
>          Issue Type: Wish
>          Components: Dependencies
>    Affects Versions: 3.3.3
>            Reporter: Stephane Nicoll
>            Priority: Trivial
>
> When a project extends from a parent with a {{dependencyManagement}} section, it is not always possible to properly override (and align) the version to use for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure their versions are consistent. 
> The following project demonstrates the issue: https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with version A and we use the same bom with version B in the child. Version B is used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom in the parent, we use a direct dependency (provided by that bom). We still use the bom with a different version. In that case all the dependencies but the one provided by the parent are overridden (leading to mixed versions for the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the graph of dependencies should be flatten at each step for a proper override. 
> Thoughts? Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)