[
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:23 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:
{{ [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?
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
