[MASSEMBLY-337] dependencySet with unpack=true cannot be used to make file permissions executable

• Type: Bug
• Status: Closed
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 2.2-beta-2
• Fix Version/s: 2.2
• Environment: Maven 2.0.9, Java 1.6_04, tested on both Windows XP and CentOS 4.1
• Assignee: John Dennis Casey
• Reporter: John Crim
• Created: 03/Jul/08 19:23
• Updated: 23/Feb/11 06:28
• Resolved: 22/Sep/10 16:06

Description

The attached tar.gz contains 2 simple test projects which exhibit this bug:

1. Project scripts-assembly generates scripts-assembly-1.0-SNAPSHOT-scripts.zip, which contains a single file, script.sh, with permissions -rwxr-xr-x
2. Project assembly-filemode-bug depends on project scripts-assembly. It extracts the scripts.zip file into its /bin directory when creating its assembly.

<!-- Assembly descriptor for assembly-filemode-bug project -->
  <dependencySets>

    <dependencySet>
      <outputFileNameMapping></outputFileNameMapping>
      <outputDirectory>bin</outputDirectory>
      <unpack>true</unpack>
      <includes>
        <include>maven-bugs:scripts-assembly:zip:scripts</include>
      </includes>
      <fileMode>0755</fileMode>
    </dependencySet>

  </dependencySets>

The fileMode element does not have the desired effect. I'm not able to find a workaround with 2.2-beta-2 that enables me to set the executable bit on the scripts. From looking at other bugs in MASSEMBLY, I did try configuring the scripts-assembly project to output a zip (also tried tar.gz) containing the files with the executable bit set. This didn't change the outcome - the files in package #2 are still not executable.

I consider this a highest priority bug, b/c I can find no way to get around this limitation and make script files from a dependency executable within an installable package. If I change to assembly plugin version 2.2-beta-1 (which admittedly has a significant list of bugs I'd like to avoid), this works. I've also tried using other tar.gz for the assembly output of both projects, but it didn't affect the outcome.

At this point I think my best path forward is to use assembly plugin version 2.2-beta-1.