Maven 2.x Assembly Plugin

Assembly plugin removes file permissions

Details

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

Description

I have some files with the execute permission set. When they are copied into a zip file by the assembly plugin their permissions are removed.

This forces me to do something ugly (and not efficient) like this:

<!-- Copy sh files so that we can set their permissions. This is required since the
         Assembly plugin looses file permissions. -->
    <dependencySet>
      <!-- This shouldn't be required but there's a bug in version 2.2-beta-1 of the Assembly
           plugin where the artifact name will be used instead of / if outputFileNameMapping is
           not specified -->
      <outputFileNameMapping></outputFileNameMapping>
      <includes>
        <include>com.xpn.xwiki.platform:xwiki-jetty-resources</include>
      </includes>
      <outputDirectory>/</outputDirectory>
      <unpack>true</unpack>
      <unpackOptions>
        <includes>
          <include>**/*.sh</include>
        </includes>
      </unpackOptions>
      <fileMode>755</fileMode>
    </dependencySet>
    <!-- Copy all other files (excluding sh files). See above for details. -->
    <dependencySet>
      <!-- This shouldn't be required but there's a bug in version 2.2-beta-1 of the Assembly
           plugin where the artifact name will be used instead of / if outputFileNameMapping is
           not specified -->
      <outputFileNameMapping></outputFileNameMapping>
      <includes>
        <include>com.xpn.xwiki.platform:xwiki-jetty-resources</include>
      </includes>
      <outputDirectory>/</outputDirectory>
      <unpack>true</unpack>
      <unpackOptions>
        <excludes>
          <exclude>**/*.sh</exclude>
        </excludes>
      </unpackOptions>
    </dependencySet>

Issue Links

This issue is related to:
MASSEMBLY-75 Unpacked TAR dependencies do not preserve file mode nor uid/gid Major Reopened
MASSEMBLY-379 Follow-up: file permissions are removed when creating tar.gz assembly Major Closed
This issue depends upon:
PLXCOMP-94 Archiver should have an option to preserve directory/file mode Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Joshua Pollak added a comment -

I can confirm this problem. It only seems to happen with zip files, permissions are preserved with tar.gz and tar.bz2.

Show
Joshua Pollak added a comment - I can confirm this problem. It only seems to happen with zip files, permissions are preserved with tar.gz and tar.bz2.
Hide
Permalink
Brian Albers added a comment -

I found that the suggested workaround – listing the <dependencySet> twice, once with <fileMode> set – did not work, because the archiver detects that the same <dependencySet> has been declared twice, and "optimizes" by skipping the second one.

Show
Brian Albers added a comment - I found that the suggested workaround – listing the <dependencySet> twice, once with <fileMode> set – did not work, because the archiver detects that the same <dependencySet> has been declared twice, and "optimizes" by skipping the second one.
Hide
Permalink
John Casey added a comment -

should be fixed, if no file/dir mode is specified...this will be in 2.2-beta-3

Show
John Casey added a comment - should be fixed, if no file/dir mode is specified...this will be in 2.2-beta-3
Hide
Permalink
Vincent Massol added a comment -

Hi John,

Just upgraded to 2.2 beta 3 and the problem still exists. I have a zip (generated iself by the assembly plugin). If I unzip it manually using unzip command on mac I get the file permissions fine but if I create another zip using the assembly plugin and I unpack it in there then the resulting zip looses the permissions.

Anything you'd like me to try?

Thanks and sorry to reopen an issue...

Show
Vincent Massol added a comment - Hi John, Just upgraded to 2.2 beta 3 and the problem still exists. I have a zip (generated iself by the assembly plugin). If I unzip it manually using unzip command on mac I get the file permissions fine but if I create another zip using the assembly plugin and I unpack it in there then the resulting zip looses the permissions. Anything you'd like me to try? Thanks and sorry to reopen an issue...
Hide
Permalink
Vincent Massol added a comment -

BTW as mentioned above by Brian you cannot declare several times the same dependencySet anymore in 2.2 beta 3 (it used to work in 2.2 beta 1)

Show
Vincent Massol added a comment - BTW as mentioned above by Brian you cannot declare several times the same dependencySet anymore in 2.2 beta 3 (it used to work in 2.2 beta 1)
Hide
Permalink
Vincent Massol added a comment -

This can be tried by building the following module:
http://svn.xwiki.org/svnroot/xwiki/enterprise/trunk/distribution/jetty/hsqldb/

Note that you'll need to modify the application.xml file here to remove the "hack":
http://svn.xwiki.org/svnroot/xwiki/enterprise/trunk/distribution/jetty/hsqldb/src/assemble/application.xml

It should look like:

<!--
 *
 * See the NOTICE file distributed with this work for additional
 * information regarding copyright ownership.
 *
 * This is free software; you can redistribute it and/or modify it
 * under the terms of the GNU Lesser General Public License as
 * published by the Free Software Foundation; either version 2.1 of
 * the License, or (at your option) any later version.
 *
 * This software is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this software; if not, write to the Free
 * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
 * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
 *
-->

<assembly>
  <formats>
    <format>tar.gz</format>
  </formats>
  <includeBaseDirectory>true</includeBaseDirectory>
  <dependencySets>
    <!-- XWiki webapp. -->
    <dependencySet>
      <!-- This shouldn't be required but there's a bug in version 2.2-beta-1 of the Assembly
           plugin where the artifact name will be used instead of / if outputFileNameMapping is
           not specified -->
      <outputFileNameMapping></outputFileNameMapping>
      <useProjectArtifact>false</useProjectArtifact>
      <includes>
        <include>com.xpn.xwiki.products:xwiki-enterprise-web</include>
      </includes>
      <outputDirectory>webapps/xwiki</outputDirectory>
      <unpack>true</unpack>
      <unpackOptions>
        <excludes>
          <exclude>**/hibernate.cfg.xml</exclude>
        </excludes>
      </unpackOptions>
    </dependencySet>
    <!-- ROOT webapp, redirecting to /xwiki/ when no application is specified. -->
    <dependencySet>
      <!-- This shouldn't be required but there's a bug in version 2.2-beta-1 of the Assembly
           plugin where the artifact name will be used instead of / if outputFileNameMapping is
           not specified -->
      <outputFileNameMapping></outputFileNameMapping>
      <useProjectArtifact>false</useProjectArtifact>
      <includes>
        <include>com.xpn.xwiki.platform.tools:xwiki-rootwebapp</include>
      </includes>
      <outputDirectory>webapps/root</outputDirectory>
      <unpack>true</unpack>
    </dependencySet>
    <dependencySet>
      <!-- This shouldn't be required but there's a bug in version 2.2-beta-1 of the Assembly
           plugin where the artifact name will be used instead of / if outputFileNameMapping is
           not specified -->
      <outputFileNameMapping></outputFileNameMapping>
      <useProjectArtifact>false</useProjectArtifact>
      <includes>
        <include>com.xpn.xwiki.platform.tools:xwiki-jetty-resources</include>
      </includes>
      <outputDirectory>/</outputDirectory>
      <unpack>true</unpack>
    </dependencySet>
    <dependencySet>
      <useProjectArtifact>false</useProjectArtifact>
      <includes>
        <include>${xwiki.db.jdbc.groupId}:${xwiki.db.jdbc.artifactId}</include>
      </includes>
      <outputDirectory>webapps/xwiki/WEB-INF/lib</outputDirectory>
      <unpack>false</unpack>
    </dependencySet>
    <dependencySet>
      <!-- This shouldn't be required but there's a bug in version 2.2-beta-1 of the Assembly
           plugin where the artifact name will be used instead of / if outputFileNameMapping is
           not specified -->
      <outputFileNameMapping></outputFileNameMapping>
      <useProjectArtifact>false</useProjectArtifact>
      <includes>
        <include>com.xpn.xwiki.products:xwiki-enterprise-database-${xwiki.db}</include>
      </includes>
      <outputDirectory>/database</outputDirectory>
      <unpack>true</unpack>
    </dependencySet>
  </dependencySets>
  <files>
    <file>
      <source>${basedir}/target/maven-shared-archive-resources/hibernate.cfg.xml</source>
      <outputDirectory>webapps/xwiki/WEB-INF</outputDirectory>
    </file>
  </files>
  <fileSets>
    <!-- Add License/Notice files -->
    <fileSet>
      <directory>${basedir}/target/maven-shared-archive-resources/META-INF</directory>
      <outputDirectory>META-INF</outputDirectory>
    </fileSet>
  </fileSets>
</assembly>
Show
Vincent Massol added a comment - This can be tried by building the following module: http://svn.xwiki.org/svnroot/xwiki/enterprise/trunk/distribution/jetty/hsqldb/ Note that you'll need to modify the application.xml file here to remove the "hack": http://svn.xwiki.org/svnroot/xwiki/enterprise/trunk/distribution/jetty/hsqldb/src/assemble/application.xml It should look like: 
<!--
 *
 * See the NOTICE file distributed with this work for additional
 * information regarding copyright ownership.
 *
 * This is free software; you can redistribute it and/or modify it
 * under the terms of the GNU Lesser General Public License as
 * published by the Free Software Foundation; either version 2.1 of
 * the License, or (at your option) any later version.
 *
 * This software is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this software; if not, write to the Free
 * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
 * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
 *
-->

<assembly>
  <formats>
    <format>tar.gz</format>
  </formats>
  <includeBaseDirectory>true</includeBaseDirectory>
  <dependencySets>
    <!-- XWiki webapp. -->
    <dependencySet>
      <!-- This shouldn't be required but there's a bug in version 2.2-beta-1 of the Assembly
           plugin where the artifact name will be used instead of / if outputFileNameMapping is
           not specified -->
      <outputFileNameMapping></outputFileNameMapping>
      <useProjectArtifact>false</useProjectArtifact>
      <includes>
        <include>com.xpn.xwiki.products:xwiki-enterprise-web</include>
      </includes>
      <outputDirectory>webapps/xwiki</outputDirectory>
      <unpack>true</unpack>
      <unpackOptions>
        <excludes>
          <exclude>**/hibernate.cfg.xml</exclude>
        </excludes>
      </unpackOptions>
    </dependencySet>
    <!-- ROOT webapp, redirecting to /xwiki/ when no application is specified. -->
    <dependencySet>
      <!-- This shouldn't be required but there's a bug in version 2.2-beta-1 of the Assembly
           plugin where the artifact name will be used instead of / if outputFileNameMapping is
           not specified -->
      <outputFileNameMapping></outputFileNameMapping>
      <useProjectArtifact>false</useProjectArtifact>
      <includes>
        <include>com.xpn.xwiki.platform.tools:xwiki-rootwebapp</include>
      </includes>
      <outputDirectory>webapps/root</outputDirectory>
      <unpack>true</unpack>
    </dependencySet>
    <dependencySet>
      <!-- This shouldn't be required but there's a bug in version 2.2-beta-1 of the Assembly
           plugin where the artifact name will be used instead of / if outputFileNameMapping is
           not specified -->
      <outputFileNameMapping></outputFileNameMapping>
      <useProjectArtifact>false</useProjectArtifact>
      <includes>
        <include>com.xpn.xwiki.platform.tools:xwiki-jetty-resources</include>
      </includes>
      <outputDirectory>/</outputDirectory>
      <unpack>true</unpack>
    </dependencySet>
    <dependencySet>
      <useProjectArtifact>false</useProjectArtifact>
      <includes>
        <include>${xwiki.db.jdbc.groupId}:${xwiki.db.jdbc.artifactId}</include>
      </includes>
      <outputDirectory>webapps/xwiki/WEB-INF/lib</outputDirectory>
      <unpack>false</unpack>
    </dependencySet>
    <dependencySet>
      <!-- This shouldn't be required but there's a bug in version 2.2-beta-1 of the Assembly
           plugin where the artifact name will be used instead of / if outputFileNameMapping is
           not specified -->
      <outputFileNameMapping></outputFileNameMapping>
      <useProjectArtifact>false</useProjectArtifact>
      <includes>
        <include>com.xpn.xwiki.products:xwiki-enterprise-database-${xwiki.db}</include>
      </includes>
      <outputDirectory>/database</outputDirectory>
      <unpack>true</unpack>
    </dependencySet>
  </dependencySets>
  <files>
    <file>
      <source>${basedir}/target/maven-shared-archive-resources/hibernate.cfg.xml</source>
      <outputDirectory>webapps/xwiki/WEB-INF</outputDirectory>
    </file>
  </files>
  <fileSets>
    <!-- Add License/Notice files -->
    <fileSet>
      <directory>${basedir}/target/maven-shared-archive-resources/META-INF</directory>
      <outputDirectory>META-INF</outputDirectory>
    </fileSet>
  </fileSets>
</assembly>
Hide
Permalink
John Casey added a comment -

This is fixed. I've tested it manually on my localhost, but I still need to write a test for it before closing.

Show
John Casey added a comment - This is fixed. I've tested it manually on my localhost, but I still need to write a test for it before closing.
Hide
Permalink
John Casey added a comment -

this doesn't have an integration test in the assembly plugin yet, but there are unit tests in place for tar and zip archives in the plexus-archiver project. Once we find a decent way to incorporate the OS-specific verification parts in place, we can add an integration test to the assembly plugin.

Show
John Casey added a comment - this doesn't have an integration test in the assembly plugin yet, but there are unit tests in place for tar and zip archives in the plexus-archiver project. Once we find a decent way to incorporate the OS-specific verification parts in place, we can add an integration test to the assembly plugin.
Hide
Permalink
Sergiu Dumitriu added a comment -

There seems to be a problem with the new code, it creates a slightly invalid zip file. Although it can be extracted by unzip, trying to open it in midnight commander (as a virtual filesystem) fails ("Inconsistent extfs archive"). Some of the directories have wrong permission modes ("Unix file attributes (177777 octal): ?rwsrwsrwt", used to be "Unix file attributes (040755 octal): drwxr-xr-x" in beta-3).

Show
Sergiu Dumitriu added a comment - There seems to be a problem with the new code, it creates a slightly invalid zip file. Although it can be extracted by unzip, trying to open it in midnight commander (as a virtual filesystem) fails ("Inconsistent extfs archive"). Some of the directories have wrong permission modes ("Unix file attributes (177777 octal): ?rwsrwsrwt", used to be "Unix file attributes (040755 octal): drwxr-xr-x" in beta-3).
Hide
Permalink
Hung Huynh added a comment -

I still see this problem with latest version 2.2.1. Building a .tar.gz package from existing files with execution permission and after I untar it, those permission are gone.

Show
Hung Huynh added a comment - I still see this problem with latest version 2.2.1. Building a .tar.gz package from existing files with execution permission and after I untar it, those permission are gone.

People

Vote (11)
Watch (13)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.