Properly inherit parent dependency management in child dependency management.
-----------------------------------------------------------------------------

                 Key: MNG-5038
                 URL: http://jira.codehaus.org/browse/MNG-5038
             Project: Maven 2 & 3
          Issue Type: Bug
          Components: Dependencies
            Reporter: Maarten Billemont


say I have a pom artifact a, with a dependencyManagement section that says 
something like:

{{
            <dependency>
                <groupId>my.company</groupId>
                <artifactId>some-lib</artifactId>
                <version>${some-lib.version}</version>
                <type>jar</type>
                <exclusions>
                    <exclusion>
                        <!-- Damnit people, stop depending on logger 
implementations -->
                        <groupId>commons-logging</groupId>
                        <artifactId>commons-logging</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>
}}

This artifact marks the top-level pom of a multi-module project.  There's a 
child pom artifact a:b, with a depedencyManagement section that says something 
like:


{{
            <dependency>
                <groupId>my.company</groupId>
                <artifactId>some-lib</artifactId>
                <scope>provided</scope>
            </dependency>
}}


Only, that doesn't fly.  a:b's dependency element doesn't inherit from a's.  In 
fact, even if I explicitly added in the version to make maven find the right 
dependency node, it would still forget about my parent's exclusion.

Which means that a:b's dependencyManagement doesn't override a's, it *replaces* 
it.  And that's a real and serious pain, because now I need to COPY a's 
dependencyManagement code into a:b wherever I want to amend it, leaving me to 
configure all my excludes in two places.  You can imagine the complete and 
utter lack of consistency between a:b and a's dependencyManagement excludes 
after 2 years of trying to maintain this sort of set-up, with all the 
unexpected bugs that result from it.

"Hey, why is commons-logging in our build, it's excluded!", no it's not, 
somebody decided to amend some lib that depends on it in a:b and now suddenly 
it's back in.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to