Maven Assembly Plugin
  1. Maven Assembly Plugin
  2. MASSEMBLY-285

regression: duplicate files added to the assembly

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.2-beta-1
    • Fix Version/s: 2.2-beta-3
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      I found that it was possible to add a file twice to the assembly through different filesets (a zip file) so that when it extracted it prompted for overwrite.

      It should error out or collapse the entries (as 2.1 did).

        Issue Links

          Activity

          Hide
          Julien CARSIQUE added a comment - - edited

          There's still a missing behavior which is "replace/update/overwrite" like zip "-u" option.
          I need this and I guess it's the most wanted behavior when archiving files already present in a zip, we often want to update/replace the file already archived, not to skip the new one (or preserve the old one).

          Please reopen issue as the fix doesn't provide same behavior as what was produced by version 2.1 (overwrite old files with new ones).

          For testing, I use the following assembly and expect files in the zip being those from resources_new directory:
          <assembly>
          <id>resources-test</id>
          <formats>
          <format>zip</format>
          </formats>
          <includeBaseDirectory>false</includeBaseDirectory>
          <fileSets>
          <fileSet>
          <directory>src/main/resources_old</directory>
          <outputDirectory>/</outputDirectory>
          </fileSet>
          <fileSet>
          <directory>src/main/resources_new</directory>
          <outputDirectory>/</outputDirectory>
          </fileSet>
          </fileSets>
          </assembly>

          Show
          Julien CARSIQUE added a comment - - edited There's still a missing behavior which is "replace/update/overwrite" like zip "-u" option. I need this and I guess it's the most wanted behavior when archiving files already present in a zip, we often want to update/replace the file already archived, not to skip the new one (or preserve the old one). Please reopen issue as the fix doesn't provide same behavior as what was produced by version 2.1 (overwrite old files with new ones). For testing, I use the following assembly and expect files in the zip being those from resources_new directory: <assembly> <id>resources-test</id> <formats> <format>zip</format> </formats> <includeBaseDirectory>false</includeBaseDirectory> <fileSets> <fileSet> <directory>src/main/resources_old</directory> <outputDirectory>/</outputDirectory> </fileSet> <fileSet> <directory>src/main/resources_new</directory> <outputDirectory>/</outputDirectory> </fileSet> </fileSets> </assembly>
          Hide
          Daniel Huss added a comment -

          Why has this been flagged as fixed? If two filesets contain files with identical names, I still get those awkward duplicates (2.2 beta5 and final):

          	<fileSet>
          			<!-- copy indexer and its dependencies-->
          			<directory>${project.build.directory}/deps/indexer</directory>
          			<outputDirectory>glassfishv3/glassfish/domains/domain1/autodeploy/jobservice/WEB-INF/lib</outputDirectory>
          		</fileSet>
          		<fileSet>
          			<!-- deploy jobservice to glassfish from unpacked WAR -->
          			<directory>${project.build.directory}/deps/jobservice</directory>
          			<outputDirectory>glassfishv3/glassfish/domains/domain1/autodeploy/jobservice</outputDirectory>
          		</fileSet>
          

          Show
          Daniel Huss added a comment - Why has this been flagged as fixed? If two filesets contain files with identical names, I still get those awkward duplicates (2.2 beta5 and final): <fileSet> <!-- copy indexer and its dependencies--> <directory> ${project.build.directory}/deps/indexer </directory> <outputDirectory> glassfishv3/glassfish/domains/domain1/autodeploy/jobservice/WEB-INF/lib </outputDirectory> </fileSet> <fileSet> <!-- deploy jobservice to glassfish from unpacked WAR --> <directory> ${project.build.directory}/deps/jobservice </directory> <outputDirectory> glassfishv3/glassfish/domains/domain1/autodeploy/jobservice </outputDirectory> </fileSet>
          Hide
          Andreas Pieber added a comment -

          Please reopen this issue. I've the same problems as Daniel

          thanks

          Show
          Andreas Pieber added a comment - Please reopen this issue. I've the same problems as Daniel thanks
          Hide
          Chad McHenry added a comment -

          This is still an issue in maven-assembly-plugin-2.2.2.

          The maven-shade-plugin (mentioned in jar-with-dependencies pre-defined descriptor) can create standalone (uber) jars and does not duplicate files.

          <!-- Shade can create a standalone jar -->
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-shade-plugin</artifactId>
            <version>1.5</version>
            <executions>
              <execution>
                <phase>package</phase>
                <goals><goal>shade</goal></goals>
                <configuration>
                  <transformers>
                    <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                      <mainClass>${mainClass}</mainClass>
                    </transformer>
                  </transformers>
                  <shadedArtifactAttached>true</shadedArtifactAttached>
                  <shadedClassifierName>standalone</shadedClassifierName>
                </configuration>
              </execution>
            </executions>
          </plugin>
          
          Show
          Chad McHenry added a comment - This is still an issue in maven-assembly-plugin-2.2.2. The maven-shade-plugin (mentioned in jar-with-dependencies pre-defined descriptor) can create standalone (uber) jars and does not duplicate files. <!-- Shade can create a standalone jar --> <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-shade-plugin </artifactId> <version> 1.5 </version> <executions> <execution> <phase> package </phase> <goals> <goal> shade </goal> </goals> <configuration> <transformers> <transformer implementation= "org.apache.maven.plugins.shade.resource.ManifestResourceTransformer" > <mainClass> ${mainClass} </mainClass> </transformer> </transformers> <shadedArtifactAttached> true </shadedArtifactAttached> <shadedClassifierName> standalone </shadedClassifierName> </configuration> </execution> </executions> </plugin>
          Hide
          Eric Daigneault added a comment -

          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.

          Show
          Eric Daigneault added a comment - 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.

            People

            • Assignee:
              John Casey
              Reporter:
              Brett Porter
            • Votes:
              20 Vote for this issue
              Watchers:
              32 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: