[
https://jira.codehaus.org/browse/MASSEMBLY-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355291#comment-355291
]
Kristian Rosenvold edited comment on MASSEMBLY-597 at 10/30/14 4:03 PM:
------------------------------------------------------------------------
Using the enclosed project it looks correct to me. I tried both maven 2.2.1 and
3.x and the output looks entirely correct. This was on mac/jdk8. I even tried a
fair number of different versions of the assembly plugin, and they all look
correct. Exactly what are you seeing ?
Actually, you might want to try assembly version 2.5 (or 2.5.1), since there
was a windows-related path bug that was fixed for 2.5
was (Author: krosenvold):
Using the enclosed project it looks correct to me. I tried both maven 2.2.1 and
3.x and the output looks entirely correct. This was on mac/jdk8. I even tried a
fair number of different versions of the assembly plugin, and they all look
correct. Exactly what are you seeing ?
> Duplicate files added to archive when present in both dependencyset and
> fileset of the same assembly
> ----------------------------------------------------------------------------------------------------
>
> Key: MASSEMBLY-597
> URL: https://jira.codehaus.org/browse/MASSEMBLY-597
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Affects Versions: 2.2.2
> Environment: windows 7, Eclipse indigo though the problem is
> reproducible from command line build. Java 6 32 bit
> Reporter: Eric Daigneault
> Attachments: ma597.zip
>
>
> Comment added to parent bug, could not re-open the issue so I created this
> sub-task instead. Comment copied here for convenience :
> ----
> Either version 2.2.2 of the Assembly plugin has a regression or the issue has
> not been fixed. I am currently creating zip files from the assembly that
> contains duplicate jar files.
> Some background : I am using the assembly to create a zip file of an
> application. Why Zip ? because the application requires multiple
> configuration files and spans larger than just Java so I cannot use a uber
> Jar (I would prefer that but technical limitations out of my control force me
> otherwise).
> This package is built correctly.
> To make life simpler I made it possible to extend this package with a project
> that can add extra classes (plugins and such) and configuration from a
> standard layout in the project that gets picked up by the assembly and merged
> with the previous vanilla package. the end result is a fully assembled zip
> file with all the customized parts in the right place.
> Now, behaviour changed across version wheras previously I would overwrite the
> original package with the content of the new one, now I have to start from
> the overrides and complete withe the original files. Easily fixed through
> changing the order I declared the filesets in the assembly. When using
> filesets strictly nothing gets added twice, though the replace was changed to
> skip which is a bit counter intuitive.
> BUT....
> Since I extend some parts of the original system, I will share some
> dependencies with this one. These dependencies are already present in the
> original package and get added through a file set (I get the package and
> unzip it in a temporary folder where I integrate it`s content inthe assembly
> through a fileset).
> I also add the dependencies of the new customized project, and these get
> added twice.
> I think there is a regression here when filesets and dependencysets interact
> where if files are present in both they get added twice in the zip file. Now
> I would re-open this current task but it seems I cannot so I will open a sub
> task instead.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
