[
https://jira.codehaus.org/browse/MJBOSSPACK-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MJBOSSPACK-40:
----------------------------------------
Attachment: jboss-sar-test-2.zip
I think neither Maven 2 nor 3 handle such a scenario, i.e. child dependency of
provided dependency managed into stronger scopes, correctly in all cases.
Back in school we learned, that a project's runtime classpath consists of
dependencies with either scope {{compile}} or {{runtime}}. Both these scopes
are transitive (neglecting optional dependencies), so as the developer of
sar-module, I would expect that the dependencies on my runtime classpath are
also present on the runtime classpath of a downstream project depending on my
sar-module. Now given that {{provided}} scope is not transitive, it's
sensible/consistent to omit {{log4j}} from sar-module's runtime classpath
because a downstream project wouldn't see it either among the runtime
dependencies. I believe this is the rationale for the code in Maven 2.x and to
me this idea looks reasonable. In other words, for the {{jboss-sar-test.zip}}
at hand, I agree with the original report that the behavior seen with Maven 3.x
is wrong.
However, the implementation taken in Maven 2.x to realize this concept is buggy
as well. Let's neglect that omitting {{log4j:*compile*}} from the runtime
classpath is confusing for many users. Consider this slightly extended example
project whose dirty tree looks like:
{noformat}
[INFO] [dependency:tree {execution: default-cli}]
[INFO] org.example.jboss-sar-test:sar-module:jboss-sar:0.0.1-SNAPSHOT
[INFO] +- org.example.jboss-sar-test:jar-module:jar:0.0.1-SNAPSHOT:provided
[INFO] | \- log4j:log4j:jar:1.2.16:compile (scope managed from provided)
[INFO] \- org.example.jboss-sar-test:jar2-module:jar:0.0.1-SNAPSHOT:compile
[INFO] \- (log4j:log4j:jar:1.2.16:compile - scope managed from provided;
omitted for duplicate)
{noformat}
i.e. there is path to {{log4j}} via a parent dependency which isn't
{{provided}} and as such {{log4j}} should be included in compile/runtime
classpaths of the project. However, Maven 2.x only looks at first path (version
conflict winner), eventually dropping {{log4j}} from the runtime classpath.
Changing the declaration order of {{jar-module}} and {{jar2-module}} in the
dependency section will make {{log4j}} show up in the assembled SAR.
I think a proper solution for this scenario is to restrict scope updates via
dependency management. It simply doesn't make sense to promote child
dependencies of a provided dependency into a generally transitive scope like
compile or runtime. A similar argument holds for child dependencies of test
dependencies. In other words, the proper dependency tree for the original
example project should be:
{noformat}
[INFO] [dependency:tree {execution: default-cli}]
[INFO] org.example.jboss-sar-test:sar-module:jboss-sar:0.0.1-SNAPSHOT
[INFO] \- org.example.jboss-sar-test:jar-module:jar:0.0.1-SNAPSHOT:provided
[INFO] \- log4j:log4j:jar:1.2.16:provided (not updated to compile)
{noformat}
i.e. leaving {{log4j}} in provided scope despite the dependency management.
> Transitive dependencies specified in dependencyManagement section included in
> sar
> ---------------------------------------------------------------------------------
>
> Key: MJBOSSPACK-40
> URL: https://jira.codehaus.org/browse/MJBOSSPACK-40
> Project: Maven 2.x JBoss Packaging Plugin
> Issue Type: Bug
> Components: sar
> Affects Versions: 2.2
> Environment: Windows 7, Maven 3.0.3, JDK 1.6.0.24 x64
> Reporter: Oleg Koptelov
> Assignee: Anders Hammar
> Attachments: jboss-sar-test-2.zip, jboss-sar-test.zip
>
>
> Parent project contains 2 modules: sar-module and jar-module. sar-module
> depends on jar-module with scope=provided. jar-module depends on 3rd party
> jar with scope=compile. Dependency on the 3rd party jar specified in
> dependencyManagement section of the parent pom. Execution of mvn clean
> package command produces sar which contains the 3rd party jar in the lib
> directory. If the jar removed from dependencyManagement, the jar is not
> included in the sar.
> Zip with the setup to reproduce the issue is attached.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
