You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Dennis Lundberg (JIRA)" <ji...@codehaus.org> on 2012/11/05 17:44:13 UTC
[jira] (MASSEMBLY-582) Plugin omits transitive runtime dependencies
where artifact is present with test-scope in current project
[ https://jira.codehaus.org/browse/MASSEMBLY-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Lundberg updated MASSEMBLY-582:
--------------------------------------
Description:
Let's say I have Project1, which has a runtime dependency on an artifact, e.g. Log4j, and Project2 which is defined to have a runtime dependency on Project1. Project2 defines a dependency on Log4j with test-scope.
{noformat}
P1 --runtime--> P2 --runtime--> Log4j
|
test
|
V
Log4j
{noformat}
If I define a descriptor in Project2 to include runtime dependencies, the Log4j artifact is not included in the resulting ZIP unless it is removed from Project2's dependencies first.
This can be replicated through the use of the attached map-jira-1.zip files.
1) Unzip to the filesystem
2) Execute mvn package from the maven-assembly-jira1 directory
3) Inspect the contents of the ZIP in project2/target (on *nix: unzip -l project2/target/*.zip). Note the absence of Log4j.
4) Edit project2/pom.xml to comment-out the dependency on Log4j.
5) Execute mvn package from the maven-assembly-jira1 directory
6) Inspect the contents of the ZIP in project2/target. Note the inclusion of Log4j.
This may not be entirely surprising to this plugin's developers. This is a specific issue for us since several projects define APIs and separate implementations. We depend on the API at compile-time and for testing use some implementation thereof. For example, we depend on SLF4j API and leave definition of the runtime logging implementation to some runtime, base-project (in this example, Project1). For testing purposes we need to define an SLF4j implementation, which just so happens (fancy that) to be the one we use in production. Our resulting deployable is created without the correct dependency set.
I would have expected to receive all the runtime, transitive dependencies of my dependencies whether or not I declare a test dependency on those artifacts.
was:
Let's say I have Project1, which has a runtime dependency on an artifact, e.g. Log4j, and Project2 which is defined to have a runtime dependency on Project1. Project2 defines a dependency on Log4j with test-scope.
P1 --runtime--> P2 --runtime--> Log4j
|
test
|
V
Log4j
If I define a descriptor in Project2 to include runtime dependencies, the Log4j artifact is not included in the resulting ZIP unless it is removed from Project2's dependencies first.
This can be replicated through the use of the attached map-jira-1.zip files.
1) Unzip to the filesystem
2) Execute mvn package from the maven-assembly-jira1 directory
3) Inspect the contents of the ZIP in project2/target (on *nix: unzip -l project2/target/*.zip). Note the absence of Log4j.
4) Edit project2/pom.xml to comment-out the dependency on Log4j.
5) Execute mvn package from the maven-assembly-jira1 directory
6) Inspect the contents of the ZIP in project2/target. Note the inclusion of Log4j.
This may not be entirely surprising to this plugin's developers. This is a specific issue for us since several projects define APIs and separate implementations. We depend on the API at compile-time and for testing use some implementation thereof. For example, we depend on SLF4j API and leave definition of the runtime logging implementation to some runtime, base-project (in this example, Project1). For testing purposes we need to define an SLF4j implementation, which just so happens (fancy that) to be the one we use in production. Our resulting deployable is created without the correct dependency set.
I would have expected to receive all the runtime, transitive dependencies of my dependencies whether or not I declare a test dependency on those artifacts.
> Plugin omits transitive runtime dependencies where artifact is present with test-scope in current project
> ---------------------------------------------------------------------------------------------------------
>
> Key: MASSEMBLY-582
> URL: https://jira.codehaus.org/browse/MASSEMBLY-582
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Affects Versions: 2.2.1
> Environment: Linux, Sun 64-bit JDK 1.6.24
> Reporter: Michael
> Attachments: map-jira-1.zip
>
>
> Let's say I have Project1, which has a runtime dependency on an artifact, e.g. Log4j, and Project2 which is defined to have a runtime dependency on Project1. Project2 defines a dependency on Log4j with test-scope.
> {noformat}
> P1 --runtime--> P2 --runtime--> Log4j
> |
> test
> |
> V
> Log4j
> {noformat}
> If I define a descriptor in Project2 to include runtime dependencies, the Log4j artifact is not included in the resulting ZIP unless it is removed from Project2's dependencies first.
> This can be replicated through the use of the attached map-jira-1.zip files.
> 1) Unzip to the filesystem
> 2) Execute mvn package from the maven-assembly-jira1 directory
> 3) Inspect the contents of the ZIP in project2/target (on *nix: unzip -l project2/target/*.zip). Note the absence of Log4j.
> 4) Edit project2/pom.xml to comment-out the dependency on Log4j.
> 5) Execute mvn package from the maven-assembly-jira1 directory
> 6) Inspect the contents of the ZIP in project2/target. Note the inclusion of Log4j.
> This may not be entirely surprising to this plugin's developers. This is a specific issue for us since several projects define APIs and separate implementations. We depend on the API at compile-time and for testing use some implementation thereof. For example, we depend on SLF4j API and leave definition of the runtime logging implementation to some runtime, base-project (in this example, Project1). For testing purposes we need to define an SLF4j implementation, which just so happens (fancy that) to be the one we use in production. Our resulting deployable is created without the correct dependency set.
> I would have expected to receive all the runtime, transitive dependencies of my dependencies whether or not I declare a test dependency on those artifacts.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira