You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Daniel Kulp (JIRA)" <ji...@codehaus.org> on 2007/03/21 16:30:35 UTC
[jira] Created: (MDEP-76) It would be nice to analyze
dependencyManagement exclusions as well as versions
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
Assigned To: Brian Fox
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
[jira] Issue Comment Edited: (MDEP-76) It would be nice to analyze
dependencyManagement exclusions as well as versions
Posted by "Joe Littlejohn (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Issue Comment Edited: (MDEP-76) It would be nice to analyze
dependencyManagement exclusions as well as versions
Posted by "Joe Littlejohn (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Commented: (MDEP-76) It would be nice to analyze
dependencyManagement exclusions as well as versions
Posted by "Joe Littlejohn (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MDEP-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260432#action_260432 ]
Joe Littlejohn commented on MDEP-76:
------------------------------------
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
[jira] Closed: (MDEP-76) It would be nice to analyze
dependencyManagement exclusions as well as versions
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MDEP-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Fox closed MDEP-76.
-------------------------
Resolution: Fixed
Fix Version/s: 2.0-alpha-4
> 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
> Assigned To: 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
[jira] Issue Comment Edited: (MDEP-76) It would be nice to analyze
dependencyManagement exclusions as well as versions
Posted by "Joe Littlejohn (JIRA)" <ji...@codehaus.org>.
[ 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