[
https://issues.apache.org/jira/browse/MASSEMBLY-894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Evans updated MASSEMBLY-894:
---------------------------------
Description:
Consider the following dependencies
* {{moduleA}} depends on moduleB, at {{compile}} scope, which in turn depends
on {{libraryX}}, also at {{compile}} scope
* {{moduleA}} also depends on {{libraryX directly}}, but at a {{test}} scope
In this scenario, when defining a {{dependencySet}} to capture the {{runtime}}
dependencies of moduleA, I would expect libraryX to be included, but it seems
it's not. That's because the {{test}} scope we use directly in {{moduleA}} is
overriding the {{compile}} scope from {{moduleB}}. I would think that the
dependency should be included, as its a compile (and thus runtime) dependency
of moduleB, and therefore of moduleA itself, even though it's not a compile
time dependency of moduleA directly. Moreover, since the direct dependency
from moduleA is at a test scope, it should be completely ignored by the plugin,
which should be only looking at {{runtime}} scope.
I have created a sample project to illustrate this behavior
[here|https://github.com/jeff303/maven-assembly-plugin-issues]. If you run
{{mvn clean package}}, the {{jackson-core}} jars (and others) do not end up in
the final distribution. I observed this behavior in version 2.6 of the plugin,
but also tried with 3.1.0 and saw the same (although the debug output differed
somewhat). If you change the scope on line 76 of the root {{pom.xml}} file to
{{compile}} instead, then it works as expected.
was:
Consider the following dependencies
* moduleA (compile) depends on moduleB (compile) which depends on libraryX
(compile)
* moduleA also depends on libraryX directly, but at a test scope
In this scenario, when defining a dependencySet to capture the runtime
dependencies of moduleA, I would expect libraryX to be included, but it seems
it's not. That's because the test scope we use directly in moduleA is
overriding the compile scope from moduleB. I would think that the dependency
should be included, as its a compile (and thus runtime) dependency of moduleB,
and therefore of moduleA itself, even though it's not a compile time dependency
of moduleA directly.
I have attached a sample project to illustrate this behavior. If you run {{mvn
package}}, the {{jackson-core}} jars (and others) do not end up in the final
distribution. I observed this behavior in version 2.6 of the plugin, but also
tried with 3.1.0 and saw the same (although the debug output differed somewhat).
> Test scope dependency causes compile time dependency to be excluded
> -------------------------------------------------------------------
>
> Key: MASSEMBLY-894
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-894
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet, filtering
> Affects Versions: 3.1.0
> Reporter: Jeff Evans
> Priority: Minor
>
> Consider the following dependencies
> * {{moduleA}} depends on moduleB, at {{compile}} scope, which in turn
> depends on {{libraryX}}, also at {{compile}} scope
> * {{moduleA}} also depends on {{libraryX directly}}, but at a {{test}} scope
> In this scenario, when defining a {{dependencySet}} to capture the
> {{runtime}} dependencies of moduleA, I would expect libraryX to be included,
> but it seems it's not. That's because the {{test}} scope we use directly in
> {{moduleA}} is overriding the {{compile}} scope from {{moduleB}}. I would
> think that the dependency should be included, as its a compile (and thus
> runtime) dependency of moduleB, and therefore of moduleA itself, even though
> it's not a compile time dependency of moduleA directly. Moreover, since the
> direct dependency from moduleA is at a test scope, it should be completely
> ignored by the plugin, which should be only looking at {{runtime}} scope.
> I have created a sample project to illustrate this behavior
> [here|https://github.com/jeff303/maven-assembly-plugin-issues]. If you run
> {{mvn clean package}}, the {{jackson-core}} jars (and others) do not end up
> in the final distribution. I observed this behavior in version 2.6 of the
> plugin, but also tried with 3.1.0 and saw the same (although the debug output
> differed somewhat). If you change the scope on line 76 of the root
> {{pom.xml}} file to {{compile}} instead, then it works as expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
