[
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
