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

Unpacked TAR dependencies do not preserve file mode nor uid/gid

    Details

    • Type: Bug Bug
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      "TAR" Assemblies generated from unpacking another TAR do not preserver the extended file information (uid/gid/mod). For example:

      if bar.tar contains an executable file "baz" and

      if our .pom has the following dependency:

          <dependency>
            <groupId>foo</groupId>
            <artifactId>bar</artifactId>
            <type>tar</type>
            <scope>compile</scope>
          </dependency>
      

      and our assembly.xml has the following:

      <assembly>
          <id></id>
          <formats>
              <format>tar.gz</format>
          </formats>
      ....
         <dependencySets>
              <dependencySet>
                  <scope>compile</scope>
                  <outputDirectory/>
                  <includes>
                      <include>foo:bar</include>
                  </includes>
                  <unpack>true</unpack>
              </dependencySet>
      

      then the generated assembly will contain "baz", but it will no longer be executable.

        Issue Links

          Activity

          Hide
          John Casey added a comment -

          I notice there is not a single test case attached to this issue. I have a series of integration tests in this plugin that are designed to tell me whether a particular issue has been fixed, in addition to unit tests in the dependency projects. Obviously, they don't cover the use cases you are describing. Maybe you have something you can contribute to help me find the issue.

          BTW, this is open source, and in Maven there is a lot to do. If you have a deadline for getting this fix done, then you may want to have a look around to see whether you can find the issue yourself. Otherwise, it depends on the few of us Maven developers finding time to put together a release, test it as best we can, and ship it.

          Show
          John Casey added a comment - I notice there is not a single test case attached to this issue. I have a series of integration tests in this plugin that are designed to tell me whether a particular issue has been fixed, in addition to unit tests in the dependency projects. Obviously, they don't cover the use cases you are describing. Maybe you have something you can contribute to help me find the issue. BTW, this is open source, and in Maven there is a lot to do. If you have a deadline for getting this fix done, then you may want to have a look around to see whether you can find the issue yourself. Otherwise, it depends on the few of us Maven developers finding time to put together a release, test it as best we can, and ship it.
          Hide
          John Casey added a comment -

          apparently not fixed; waiting for test cases to proceed.

          Show
          John Casey added a comment - apparently not fixed; waiting for test cases to proceed.
          Hide
          Heather Wells added a comment -

          Tested with 2.2-beta-3. The permissions are set correctly if <includeBaseDirectory> is set to false. As soon as it's set to true, the permissions for unpackaged tar.gz dependencies lose the executable bit.

          Show
          Heather Wells added a comment - Tested with 2.2-beta-3. The permissions are set correctly if <includeBaseDirectory> is set to false. As soon as it's set to true, the permissions for unpackaged tar.gz dependencies lose the executable bit.
          Hide
          Sarma Palli added a comment -

          Tested maven-assembly-plugin 2.2.1, with zip file.
          with Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500). Works fine when run with maven 2.

          with Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600). It is broken.
          The permissions are set correctly if <includeBaseDirectory> is set to false.
          As soon as it's set to true, the permissions for unpacked files & directories are all 000.

          Show
          Sarma Palli added a comment - Tested maven-assembly-plugin 2.2.1, with zip file. with Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500). Works fine when run with maven 2. with Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600). It is broken. The permissions are set correctly if <includeBaseDirectory> is set to false. As soon as it's set to true, the permissions for unpacked files & directories are all 000.
          Hide
          Sarma Palli added a comment -

          Figured out the problem with the zip.
          The zip I was using was created using windows (WinZip). The permissions were missing from the zip itself.
          When unpacking the zip file under maven 2, the permissions are defaulted to drwxrwxrwx for directories and -rwsrwsrwt for files.
          When unpacking the zip file under maven 3, the permissions are defaulted to d--------- for directories and ---------- for files.

          Works fine when the zip is created in Unix.

          Show
          Sarma Palli added a comment - Figured out the problem with the zip. The zip I was using was created using windows (WinZip). The permissions were missing from the zip itself. When unpacking the zip file under maven 2, the permissions are defaulted to drwxrwxrwx for directories and -rwsrwsrwt for files. When unpacking the zip file under maven 3, the permissions are defaulted to d--------- for directories and ---------- for files. Works fine when the zip is created in Unix.

            People

            • Assignee:
              John Casey
              Reporter:
              Maciej Szefler
            • Votes:
              7 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated: