maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Littlejohn (JIRA)" <j...@codehaus.org>
Subject [jira] Issue Comment Edited: (MDEP-76) It would be nice to analyze dependencyManagement exclusions as well as versions
Date Wed, 16 Mar 2011 18:25:22 GMT

    [ http://jira.codehaus.org/browse/MDEP-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260432#action_260432
] 

Joe Littlejohn edited comment on MDEP-76 at 3/16/11 1:24 PM:
-------------------------------------------------------------

I think there might now be a case where a valid dependency configuration can cause the analyze-dep-mgt
goal to fail. I'm hitting a problem with the change that has been made to fix this issue which
(funnily enough) is also related to logging.

My situation is this:
- I depend on a library that depends on log4j, my app also depends on log4j
- I'm deploying to a container that provides log4j, so I need to make sure that log4j does
not get bundled with my app
- I add an exclusion for log4j so that it is not included in my bundle (even though it is
a transitive dependency)
- I now add a log4j to dependencyManagement to the parent with scope 'provided'

When I add log4j as a dependency in a child pom, I see this error:

{code}
[INFO] [dependency:analyze-dep-mgt {execution: default}]
[INFO] Found Resolved Dependency / DependencyManagement mismatches:
[INFO] log4j:log4j:jar was excluded in DepMgt, but version 1.2.14 has been found in the dependency
tree.
{code}

I'm using {{<failBuild>true</failBuild>}} because I really want/need this feature.
I guess the bottom line is that even though I exclude an artifact from one dependency, I may
still want a direct dependency on that artifact to be valid (particularly when scope=provided).

Does this make sense?

      was (Author: joelittlejohn):
    I think there might now be a case where a valid dependency configuration can cause the
analyze-dep-mgt goal to fail. I'm hitting a problem with the change that has been made to
fix this issue which (funnily enough) is also related to logging.

My situation is this:
- I depend on a library that depends on log4j, my app also depends on log4j
- I'm deploying to a container that provides log4j, so I need to make sure that log4j does
not get bundled with my app
- I add an exclusion for log4j so that it is not included in my bundle (even though it is
a transitive dependency)
- I now add a log4j to dependencyManagement to the parent with scope 'provided'

When I add log4j as a dependency in a child pom, I see this error:

{{ [INFO] [dependency:analyze-dep-mgt {execution: default}] }}
{{ [INFO] Found Resolved Dependency / DependencyManagement mismatches: }}
{{ [INFO] log4j:log4j:jar was excluded in DepMgt, but version 1.2.14 has been found in the
dependency tree. }}

I'm using {{<failBuild>true</failBuild>}} because I really want/need this feature.
I guess the bottom line is that even though I exclude an artifact from one dependency, I may
still want a direct dependency on that artifact to be valid (particularly when scope=provided).

Does this make sense?
  
> It would be nice to analyze dependencyManagement exclusions as well as versions
> -------------------------------------------------------------------------------
>
>                 Key: MDEP-76
>                 URL: http://jira.codehaus.org/browse/MDEP-76
>             Project: Maven 2.x Dependency Plugin
>          Issue Type: Improvement
>          Components: analyze
>    Affects Versions: 2.0-alpha-3
>            Reporter: Daniel Kulp
>            Assignee: Brian Fox
>             Fix For: 2.0-alpha-4
>
>
> In my depManagment section, I do:
>             <dependency>
>                 <groupId>commons-logging</groupId>
>                 <artifactId>commons-logging</artifactId>
>                 <version>1.1</version>
>                 <exclusions>
>                     <exclusion>
>                         <groupId>log4j</groupId>
>                         <artifactId>log4j</artifactId>
>                     </exclusion>
>                 </exclusions>
>             <dependency>
> to hopefully remove log4j from the build.    However, if I depend on something else that
depends on commons-logging (like spring or neethi), they suck in log4j.    It would be nice
if the analyzer would check if the exclusions are really occuring.

-- 
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

        

Mime
View raw message