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

regression: duplicate files added to the assembly

    Details

    • Type: Bug Bug
    • Status: 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

      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
          Andrew Grande added a comment -

          2.2-beta-2 is badly broken due to this. Does it really take so much time to fix the regression? Pleease?

          Show
          Andrew Grande added a comment - 2.2-beta-2 is badly broken due to this. Does it really take so much time to fix the regression? Pleease?
          Hide
          Andrew Grande added a comment -

          This is reproduced when one tries e.g. to configure permissions on the files in the directory using multiple include/exclude patterns. Each FileSet is instead copied and duplicated in zip. E.g. real config that broke: http://svn.galaxy.muleforge.org/browse/galaxy/trunk/netboot/mule1/distribution/assembly.xml?r=487

          Show
          Andrew Grande added a comment - This is reproduced when one tries e.g. to configure permissions on the files in the directory using multiple include/exclude patterns. Each FileSet is instead copied and duplicated in zip. E.g. real config that broke: http://svn.galaxy.muleforge.org/browse/galaxy/trunk/netboot/mule1/distribution/assembly.xml?r=487
          Hide
          Alan Cabrera added a comment -

          This jacks up my world as my jar signer freaks out when it sees the duplicate files.

          Show
          Alan Cabrera added a comment - This jacks up my world as my jar signer freaks out when it sees the duplicate files.
          Hide
          Michael Mattox added a comment - - edited

          I'm having this problem too when making a WAR file.

          Any news on a possible fix?? It's been 3 weeks now without an update.

          Show
          Michael Mattox added a comment - - edited I'm having this problem too when making a WAR file. Any news on a possible fix?? It's been 3 weeks now without an update.
          Hide
          Amir Eliaz added a comment -

          This is happening also with tar.gz format.
          The resulting tar file contains many copies of several Jar artifacts, multiplying its size by ~4.
          When extracting, only one copy is left per artifact.

          Show
          Amir Eliaz added a comment - This is happening also with tar.gz format. The resulting tar file contains many copies of several Jar artifacts, multiplying its size by ~4. When extracting, only one copy is left per artifact.
          Hide
          Andrei Solntsev added a comment -

          I have a project with several submodules, each of them creates a ZIP during build.

          When I build submodules one by one, they produce correct ZIPs.
          But when i build the entire project with all submodules, their ZIPs contain duplicated entries.

          Show
          Andrei Solntsev added a comment - I have a project with several submodules, each of them creates a ZIP during build. When I build submodules one by one, they produce correct ZIPs. But when i build the entire project with all submodules, their ZIPs contain duplicated entries.
          Hide
          Artur Zielazny added a comment -

          Similar situation while assembling multimodule project to ZIP using
          <moduleSets>
          <moduleSet>
          <includes>
          ...
          in assembly.xml

          Show
          Artur Zielazny added a comment - Similar situation while assembling multimodule project to ZIP using <moduleSets> <moduleSet> <includes> ... in assembly.xml
          Hide
          gotama added a comment -

          I found this bug while trying to merge 2 <fileset> directories expecting that the 2nd would overwrite the first set of files where they overlap (in using one fileset as "default" files and the 2nd fileset as overrides).

          The result was as described in the bug - 2 identical files added to the resulting zip file. Upon extraction of the zip, I was prompted for an option to override one of the files. I also verified that the case on both files was lower case, so its NOT an issue with the same filename with different case; ie creating the archive on unix and extracting on Windows.

          This bug has been open for a long time. It would be appreciated if this was fixed ASAP. Its a huge blocker. Thanks!

          example assembly.xml file:

          <assembly xmlns="http://maven.apache.org/POM/4.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/assembly-1.1.0-SNAPSHOT.xsd">

          <id>bin</id>

          <formats>
          <format>zip</format>
          </formats>

          <fileSets>
          <fileSet>
          <!--must use absolute reference with $

          {pom.basedir} to achieve filtering -->
          <directory>${pom.basedir}

          /src/main/config/defaults/</directory>
          <outputDirectory>$

          {pom.basedir}/target/work/</outputDirectory>
          <filtered>true</filtered>
          </fileSet>
          <fileSet>
          <!-- must use absolute reference with ${pom.basedir}

          to achieve filtering -->
          <directory>$

          {pom.basedir}/src/main/config/overrides/</directory>
          <outputDirectory>${pom.basedir}

          /target/work/</outputDirectory>
          <filtered>true</filtered>
          </fileSet>
          </fileSets>

          </assembly>

          Show
          gotama added a comment - I found this bug while trying to merge 2 <fileset> directories expecting that the 2nd would overwrite the first set of files where they overlap (in using one fileset as "default" files and the 2nd fileset as overrides). The result was as described in the bug - 2 identical files added to the resulting zip file. Upon extraction of the zip, I was prompted for an option to override one of the files. I also verified that the case on both files was lower case, so its NOT an issue with the same filename with different case; ie creating the archive on unix and extracting on Windows. This bug has been open for a long time. It would be appreciated if this was fixed ASAP. Its a huge blocker. Thanks! example assembly.xml file: <assembly xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/assembly-1.1.0-SNAPSHOT.xsd "> <id>bin</id> <formats> <format>zip</format> </formats> <fileSets> <fileSet> <!--must use absolute reference with $ {pom.basedir} to achieve filtering --> <directory>${pom.basedir} /src/main/config/defaults/</directory> <outputDirectory>$ {pom.basedir}/target/work/</outputDirectory> <filtered>true</filtered> </fileSet> <fileSet> <!-- must use absolute reference with ${pom.basedir} to achieve filtering --> <directory>$ {pom.basedir}/src/main/config/overrides/</directory> <outputDirectory>${pom.basedir} /target/work/</outputDirectory> <filtered>true</filtered> </fileSet> </fileSets> </assembly>
          Hide
          gotama added a comment -

          Until this is fixed, here is an example work around, if you are interested (the modules parent is a default jboss-assembly module - the child module inherits the src and config of the default jboss-assembly):

          pom.xml:

          <plugins>

          <!-- generate resources. merge default and current configurations. -->
          <plugin>
          <artifactId>maven-antrun-plugin</artifactId>
          <executions>
          <execution>
          <phase>generate-resources</phase>
          <configuration>
          <tasks>
          <copy todir="$

          {project.build.directory}/generated-resources/"
          preservelastmodified="true" verbose="true" overwrite="true">
          <fileset dir="${basedir}/../jboss-assembly/src/main/config/"/>
          </copy>
          <copy todir="${project.build.directory}

          /generated-resources/"
          preservelastmodified="true" verbose="true" overwrite="true">
          <fileset dir="$

          {basedir}

          /src/main/config/"/>
          </copy>
          </tasks>
          </configuration>
          <goals>
          <goal>run</goal>
          </goals>
          </execution>
          </executions>
          </plugin>

          <-- maven assembly plugin -->
          </plugins>

          Show
          gotama added a comment - Until this is fixed, here is an example work around, if you are interested (the modules parent is a default jboss-assembly module - the child module inherits the src and config of the default jboss-assembly): pom.xml: <plugins> <!-- generate resources. merge default and current configurations. --> <plugin> <artifactId>maven-antrun-plugin</artifactId> <executions> <execution> <phase>generate-resources</phase> <configuration> <tasks> <copy todir="$ {project.build.directory}/generated-resources/" preservelastmodified="true" verbose="true" overwrite="true"> <fileset dir="${basedir}/../jboss-assembly/src/main/config/"/> </copy> <copy todir="${project.build.directory} /generated-resources/" preservelastmodified="true" verbose="true" overwrite="true"> <fileset dir="$ {basedir} /src/main/config/"/> </copy> </tasks> </configuration> <goals> <goal>run</goal> </goals> </execution> </executions> </plugin> <-- maven assembly plugin --> </plugins>
          Hide
          John Casey added a comment -

          You'll need to specify the following in your plugin's configuration section:

          <archiverConfig>
            <duplicateBehavior>skip</duplicateBehavior>
          </archiverConfig>
          
          Show
          John Casey added a comment - You'll need to specify the following in your plugin's configuration section: <archiverConfig> <duplicateBehavior> skip </duplicateBehavior> </archiverConfig>
          Hide
          John Casey added a comment -

          the default duplicates setting for the zip archiver is "add", meaning allow duplicates. This logic has been preserved, and using the archiverConfig element of the plugin configuration you an override it. BTW, the duplicates-handling logic from the zip archiver has been generalized out to the AbstractArchiver, so all archivers should handle it.

          Show
          John Casey added a comment - the default duplicates setting for the zip archiver is "add", meaning allow duplicates. This logic has been preserved, and using the archiverConfig element of the plugin configuration you an override it. BTW, the duplicates-handling logic from the zip archiver has been generalized out to the AbstractArchiver, so all archivers should handle it.
          Hide
          Artur Zielazny added a comment -

          With following configuration placed in parent's POM:

          <plugin>
          <artifactId>maven-assembly-plugin</artifactId>
          <version>2.2-beta-3-SNAPSHOT</version>
          <configuration>
          <archiverConfig>
          <duplicateBehaviour>skip</duplicateBehaviour>
          </archiverConfig>
          <descriptors>
          <descriptor>src/main/assembly/assembly.xml</descriptor>
          </descriptors>
          <outputDirectory>target</outputDirectory>
          </configuration>
          </plugin>

          used in multimodule project (parent, then few modules as child), this is still adding duplicates into the final ZIP archive. <duplicateBehaviour>fail</duplicateBehaviour> does not fail as well.

          I will appreciate any help.

          Show
          Artur Zielazny added a comment - With following configuration placed in parent's POM: <plugin> <artifactId>maven-assembly-plugin</artifactId> <version>2.2-beta-3-SNAPSHOT</version> <configuration> <archiverConfig> <duplicateBehaviour>skip</duplicateBehaviour> </archiverConfig> <descriptors> <descriptor>src/main/assembly/assembly.xml</descriptor> </descriptors> <outputDirectory>target</outputDirectory> </configuration> </plugin> used in multimodule project (parent, then few modules as child), this is still adding duplicates into the final ZIP archive. <duplicateBehaviour>fail</duplicateBehaviour> does not fail as well. I will appreciate any help.
          Hide
          Artur Zielazny added a comment -

          With duplicateBehavior instead of duplicateBehaviour (one letter changed) it still does not work.

          Show
          Artur Zielazny added a comment - With duplicateBehavior instead of duplicateBehaviour (one letter changed) it still does not work.
          Hide
          Antony Stubbs added a comment -

          Shouldn't the default behaviour be the 'correct' behaviour? What percentage of people actually want duplicate files in their artefacts?

          Why should we try to preserve incorrect behaviour? This sort of thing cripples products - just look at the www.

          Please point it out if there's something I'm missing.

          Show
          Antony Stubbs added a comment - Shouldn't the default behaviour be the 'correct' behaviour? What percentage of people actually want duplicate files in their artefacts? Why should we try to preserve incorrect behaviour? This sort of thing cripples products - just look at the www. Please point it out if there's something I'm missing.
          Hide
          Dan Diephouse added a comment -

          I heartily agree with Antony here - please reopen this issue!

          Show
          Dan Diephouse added a comment - I heartily agree with Antony here - please reopen this issue!
          Hide
          Alan Cabrera added a comment -

          I agree as well.

          Show
          Alan Cabrera added a comment - I agree as well.
          Hide
          Julien S added a comment -

          I just to give one more voice on the topic, I also strongly agree that the "normal" behavior is not to duplicate files.

          Show
          Julien S added a comment - I just to give one more voice on the topic, I also strongly agree that the "normal" behavior is not to duplicate files.
          Hide
          Benjamin Bentmann added a comment -

          Shouldn't the default behaviour be the 'correct' behaviour?

          +1, following Maven's spirit of "convention over configuration" where the convention of course should be sensible, i.e. cover the major use case.

          Show
          Benjamin Bentmann added a comment - Shouldn't the default behaviour be the 'correct' behaviour? +1, following Maven's spirit of "convention over configuration" where the convention of course should be sensible, i.e. cover the major use case.
          Hide
          Erik Engstrom added a comment -

          I agree that the default behaviour should be to not allow duplicates. I also think that the default should be to overwrite, not to skip. So that it works just like copying files to a directory.

          Show
          Erik Engstrom added a comment - I agree that the default behaviour should be to not allow duplicates. I also think that the default should be to overwrite, not to skip. So that it works just like copying files to a directory.
          Hide
          Alison Winters added a comment -

          I strongly agree. Every time we have to put workarounds in our poms we're just taking another step back to ant build.xmls. I honestly can't think of any case where it would be useful to have two of the same file in an archive. My vote would be to overwrite and warn.

          Show
          Alison Winters added a comment - I strongly agree. Every time we have to put workarounds in our poms we're just taking another step back to ant build.xmls. I honestly can't think of any case where it would be useful to have two of the same file in an archive. My vote would be to overwrite and warn.
          Hide
          Daniel Gredler added a comment -

          +1 on defaulting to overwrite, at least if the assembly is building a jar or a war...

          Show
          Daniel Gredler added a comment - +1 on defaulting to overwrite, at least if the assembly is building a jar or a war...
          Hide
          Antony Stubbs added a comment -

          Hi everyone, glad to see you all agree!

          Have opened a new issue to cover this, as this one has been officially closed and doesn't seem to be getting much attention:
          http://jira.codehaus.org/browse/MASSEMBLY-361

          Please go and vote for it!

          Show
          Antony Stubbs added a comment - Hi everyone, glad to see you all agree! Have opened a new issue to cover this, as this one has been officially closed and doesn't seem to be getting much attention: http://jira.codehaus.org/browse/MASSEMBLY-361 Please go and vote for it!
          Hide
          John Casey added a comment -

          investigating

          Show
          John Casey added a comment - investigating
          Hide
          John Casey added a comment -

          default behavior is set to skip. Because of the way archive resources are processed, implementing overwrite is going to be a lot more involved. From the perspective of the assembly plugin, overwrite vs. skip doesn't make much difference, since users cannot control which type of assembly section is processed first, and any of them could overwrite entries from any other. Having duplicate files that are different will lead to non-deterministic results as long as you're not talking about any two specific sections, or entries within a single section, so there is no difference in the general case between skip and overwrite.

          In terms of two fileSets, however, it makes sense to allow overwrites. Since this is pretty complex to implement in plexus-archiver, I'll create a new issue for it and assign it to 2.2 (final).

          Show
          John Casey added a comment - default behavior is set to skip. Because of the way archive resources are processed, implementing overwrite is going to be a lot more involved. From the perspective of the assembly plugin, overwrite vs. skip doesn't make much difference, since users cannot control which type of assembly section is processed first, and any of them could overwrite entries from any other. Having duplicate files that are different will lead to non-deterministic results as long as you're not talking about any two specific sections, or entries within a single section, so there is no difference in the general case between skip and overwrite. In terms of two fileSets, however, it makes sense to allow overwrites. Since this is pretty complex to implement in plexus-archiver, I'll create a new issue for it and assign it to 2.2 (final).
          Hide
          John Casey added a comment -

          verified as fixed in src/it/projects/bugs/massembly-285

          Show
          John Casey added a comment - verified as fixed in src/it/projects/bugs/massembly-285
          Hide
          Daniel Gredler added a comment -

          Let me make sure I'm clear on this. If my assembly.xml file has a "dependencySets" node (containing a single "dependencySet") followed by a "fileSets" node (containing a single "fileSet"), neither the order of the nodes nor the intrinsic meaning of the nodes affects the order in which they are processed? The processing order is non-deterministic?

          Show
          Daniel Gredler added a comment - Let me make sure I'm clear on this. If my assembly.xml file has a "dependencySets" node (containing a single "dependencySet") followed by a "fileSets" node (containing a single "fileSet"), neither the order of the nodes nor the intrinsic meaning of the nodes affects the order in which they are processed? The processing order is non-deterministic?
          Hide
          Graham Zabel added a comment -

          Is this fixed yet? I've still having the duplicate files issue with the default version of the plugin. With 2.2-beta-3 and 2.2-beta-4, there are no duplicates, but NO module dependencies are included, even using <includeDependencies>true</includeDependencies>.

          Also, 'overwrite' is not a valid duplicate-file behavior:

          [INFO] Failed to create assembly: Error creating assembly archive test-zip:
          Failed to configure archiver: org.codehaus.plexus.archiver.zip.ZipArchiver

          Invalid duplicate-file behavior: 'overwrite'. Please specify one of: [skip, add,
          preserve, fail]

          Show
          Graham Zabel added a comment - Is this fixed yet? I've still having the duplicate files issue with the default version of the plugin. With 2.2-beta-3 and 2.2-beta-4, there are no duplicates, but NO module dependencies are included, even using <includeDependencies>true</includeDependencies>. Also, 'overwrite' is not a valid duplicate-file behavior: [INFO] Failed to create assembly: Error creating assembly archive test-zip: Failed to configure archiver: org.codehaus.plexus.archiver.zip.ZipArchiver Invalid duplicate-file behavior: 'overwrite'. Please specify one of: [skip, add, preserve, fail]
          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:
              29 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development