[
https://jira.codehaus.org/browse/MASSEMBLY-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348092#comment-348092
]
Valentin Kovalenko edited comment on MASSEMBLY-701 at 6/15/14 5:07 PM:
-----------------------------------------------------------------------
_>>Why don't you organize your project based on the logical structure ..._
It's just a quick-made example of how to reproduce the bug. Location of parent
module is not related to the described behavior so why care about it? Even if
you'll refactor the location of the p-parent it will not change the described
behavior.
Originally in my actual project the module p2 (well, not p2 but its analogue)
produces an attached artifact with configuration files and the module p1
includes these configuration files into a final assembled package.
_>>Why are you creating a zip via antrun-plugin?_
Well, I didn't find an understandable way to create a zip-type attached
artifact via assembly pligun if its content comes from the same project that
should produce the artifact. Nonetheless project p2 produces an attached
artifact _p2-0.0.0-SNAPSHOT-myClassifier.zip_ and if you'll try run _mvn
install_ and check the local .m2 repo you'll see that the attached artifact is
installed correctly. For me it seems that it doesn't matter how the attached
artifact was produced. Am I wrong here?
P.S. of course _mvn clean package_ solves the problem, but this is just a work
around
was (Author: male):
_>>Why don't you organize your project based on the logical structure ..._
It's just a quick-made example of how to reproduce the bug. Location of parent
module is not related to the described behavior so why care about it? Even if
you'll refactor the location of the p-parent it will not change the described
behavior.
Originally in my actual project the module p2 (well, not p2 but its analogue)
produces an attached artifact with configuration files and the module p1
includes these configuration files into a final assembled package.
_>>Why are you creating a zip via antrun-plugin?_
Well, I didn't find an understandable way to create a zip-type attached
artifact via assembly pligun if it's content comes from the same project that
should produce the artifact. Nonetheless project p2 produces an attached
artifact _p2-0.0.0-SNAPSHOT-myClassifier.zip_ and if you'll try run _mvn
install_ and check the local .m2 repo you'll see that the attached artifact is
installed correctly. For me it seems that it doesn't matter how the attached
artifact was produced. Am I wrong here?
P.S. of course _mvn clean package_ solves the problem, but this is just a work
around
> class AddDependencySetsTask doesn't re-unpack contents of unpacked SNAPSHOT
> artifacts
> -------------------------------------------------------------------------------------
>
> Key: MASSEMBLY-701
> URL: https://jira.codehaus.org/browse/MASSEMBLY-701
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
> Affects Versions: 2.4
> Environment: Apache Maven 3.2.1, Oracle Java SE Runtime Environment
> (build 1.8.0-b132)
> Reporter: Valentin Kovalenko
> Fix For: backlog
>
> Attachments: test-Maven.zip
>
>
> Simple project [^test-Maven.zip] to reproduce the problem is attached.
> *Test case scenario:*
> 1) Upack _test-Maven.zip_ into _test-Maven_ directory.
> 2) Run _mvn package_ from the _test-Maven_ directory.
> 3) Check that content of the file
> _test-Maven\p2\target\p2-0.0.0-SNAPSHOT-myClassifier.zip\content.txt_ is
> "some content".
> 4) Check that content of the file
> _test-Maven\target\p1-0.0.0-SNAPSHOT-myClassifier.zip\myClassifier\content.txt_
> is "some content" (p2 assembly packs content of
> _p2-0.0.0-SNAPSHOT-myClassifier.zip_ into
> _p1-0.0.0-SNAPSHOT-myClassifier.zip_).
> 5) Modify content of the file _test-Maven\p2\src\myClassifier\content.txt_
> (e.g. write "a new content").
> 6) Same as 2). Run _mvn package_ from the _test-Maven_ directory.
> 7) Check that content of the file
> _test-Maven\p2\target\p2-0.0.0-SNAPSHOT-myClassifier.zip\content.txt_ has
> changed to "a new content".
> 8) Check that content of the file
> _test-Maven\target\p1-0.0.0-SNAPSHOT-myClassifier.zip\myClassifier\content.txt_
> is still "some content" and not "a new content" (+! bug+).
> Assembly plugin unpacks content of _p2-0.0.0-SNAPSHOT-myClassifier.zip_ into
> the directory
> _test-Maven\target\assembly\work\test_p2_0.0.0-SNAPSHOT_myClassifier.zip_ and
> never unpacks _p2-0.0.0-SNAPSHOT-myClassifier.zip_ again if working directory
> exists. That is +assembly plugin ignores the fact that
> _p2-0.0.0-SNAPSHOT-myClassifier.zip_ is a SNAPSHOT (the version of p2 is
> 0.0.0-SNAPSHOT)+.
> It seems like the corresponding code is in the line 238 (_if ( dir.exists()
> )_) in the class
> [org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask|http://svn.apache.org/viewvc/maven/plugins/tags/maven-assembly-plugin-2.4/src/main/java/org/apache/maven/plugin/assembly/archive/task/AddDependencySetsTask.java?view=markup#l238].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
