Maven 2.x Assembly Plugin

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

depends upon

Improvement - An improvement or enhancement to an existing feature or task. PLXCOMP-94 Archiver should have an option to preserve directory/file mode

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MASSEMBLY-238 Assembly plugin removes file permissions

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Porter added a comment -

I'd suggest the way to fix this is to add ArchiveFileSet to the archiver, which has ZipFileSet, TarFileSet, etc.

Basically, you read into the final archive straight from the source archive, without the crappy unpack step in between. It should also be faster, and we can keep everything (file times, modes, etc) where supported.

  • Brett
Show
Brett Porter added a comment - I'd suggest the way to fix this is to add ArchiveFileSet to the archiver, which has ZipFileSet, TarFileSet, etc. Basically, you read into the final archive straight from the source archive, without the crappy unpack step in between. It should also be faster, and we can keep everything (file times, modes, etc) where supported. Brett
Hide
Permalink
Brett Porter added a comment -

let's do this in conjunction with a migration to commons-compress where they are designing a clean API

Show
Brett Porter added a comment - let's do this in conjunction with a migration to commons-compress where they are designing a clean API
Hide
Permalink
Robert Watkins added a comment -

This is still an issue with 2.2-beta-1 (bit me not 30 minutes ago).

the only workaround I've got at the moment is to leave the tarballs packed up, and then manually unpack them later (as part of the actual manual installation process).

Show
Robert Watkins added a comment - This is still an issue with 2.2-beta-1 (bit me not 30 minutes ago). the only workaround I've got at the moment is to leave the tarballs packed up, and then manually unpack them later (as part of the actual manual installation process).
Hide
Permalink
Grégory Joseph added a comment -

still an issue with 2.2-beta-2, and we'd love a fix over here

Show
Grégory Joseph added a comment - still an issue with 2.2-beta-2, and we'd love a fix over here
Hide
Permalink
John Casey added a comment -

I think this is fixed as of my latest commit, but I need to add a specific test for it in plexus-archiver.

Show
John Casey added a comment - I think this is fixed as of my latest commit, but I need to add a specific test for it in plexus-archiver.
Hide
Permalink
Grégory Joseph added a comment -

Great

Show
Grégory Joseph added a comment - Great
Hide
Permalink
John Casey added a comment -

now I've added a unit test to plexus-archiver to verify this works. Unfortunately, it's no trivial task to ensure this works in an integration test for maven assembly plugin, since that IT wouldn't work on windows and we don't have a great way of marking which OSes a test should run on (at least, AFAIK).

Show
John Casey added a comment - now I've added a unit test to plexus-archiver to verify this works. Unfortunately, it's no trivial task to ensure this works in an integration test for maven assembly plugin, since that IT wouldn't work on windows and we don't have a great way of marking which OSes a test should run on (at least, AFAIK).
Hide
Permalink
Dan Carbs added a comment -

I have tested this issue with the new 2.2-beta-3 released on January 5 2009 and it is NOT fixed. To reproduce, I have a dependency for which i set the filemode of multiple files to 777. When the dependency is unpacked as specified in the descriptor the permissions are lost.

Show
Dan Carbs added a comment - I have tested this issue with the new 2.2-beta-3 released on January 5 2009 and it is NOT fixed. To reproduce, I have a dependency for which i set the filemode of multiple files to 777. When the dependency is unpacked as specified in the descriptor the permissions are lost.
Hide
Permalink
Gabe McArthur added a comment -

Tested with 2.2-beta-4, and it's still not fixed. What gives? This has supposedly been closed, but I unpackage from a ZIP archive into a TAR.GZ archive, and I get no file permissions at all. Seriously, not even read on the user level: I get '-------'. How screwy is that? Why is this not tested/fixed after 8 months?

Show
Gabe McArthur added a comment - Tested with 2.2-beta-4, and it's still not fixed. What gives? This has supposedly been closed, but I unpackage from a ZIP archive into a TAR.GZ archive, and I get no file permissions at all. Seriously, not even read on the user level: I get '-------'. How screwy is that? Why is this not tested/fixed after 8 months?
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (7)
Watch (9)

Dates

  • Created:
    Updated: