[jira] Commented: (MASSEMBLY-554) DependencySet unpackOptions 'filtered' causes unpack not to work

["Dave Combs (JIRA)" <ji...@codehaus.org>]

    [ http://jira.codehaus.org/browse/MASSEMBLY-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=262159#action_262159 ] 

Dave Combs commented on MASSEMBLY-554:
--------------------------------------

I think I found the bug, but am not sure (and do not know how to fix it, given the code): 

in looking at the plugin source file 
maven-assembly-plugin/src/main/java/org/apache/maven/plugin/assembly/archive/task/AddDependencySetsTask.java

it appears that the issue is around lines 290-300.  
My outputDirectory value is /, but the code at line 290 retrieves a filenameMapping of ${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension} 
, then evaluates that with my dependent file as 
'com.kaazing.gateway.fake1-1.1.1.1-SNAPSHOT-bin.tar.gz'

At line 300, outputLocation is computed as
  new File(outDir, filenameMapping).getPath()

I would assume for an unpacked archive that the real outputLocation should be at wherever 'outDir' points to (in my case, '/'), not with filenameMapping appended?  But I'm not exactly sure why filenameMapping is being used at all in this piece of code.

I'm wondering if I could force the filename mapping to null somehow (as the code as 293 says that will result in using 'defaultFileNameMapping', which is null in my case), but this is not obvious.

Suggestions/comments welcome.  
Dave

> DependencySet unpackOptions 'filtered' causes unpack not to work
> ----------------------------------------------------------------
>
>                 Key: MASSEMBLY-554
>                 URL: http://jira.codehaus.org/browse/MASSEMBLY-554
>             Project: Maven 2.x Assembly Plugin
>          Issue Type: Bug
>    Affects Versions: 2.2
>         Environment: Ubuntu 10.10 Linux, x86-64.  
>            Reporter: Dave Combs
>         Attachments: example.zip
>
>
> In 2.2-beta-4, the dependencySet option 'filtered' does not appear to work.  Files from a dependency end up in the right place (under / in the fragment below), but the filters are not applied.  In 2.2 it is worse--the files are correctly filtered, but a directory of the same name as the archive from which they came (com.kaazing.gateway.assembly.core.tar.gz below) is included in the output under /, rather than just the contents of the archive, and the filtered files appear there.  It's as though the archive is exploded in place under its own name.
> <dependencySet>
>   <outputDirectory>/</outputDirectory>
>   <unpack>true</unpack>
>   <unpackOptions>
>     <filtered>true</filtered>
>   </unpackOptions>
>   <includes>
>     <include>com.kaazing.gateway.core:com.kaazing.gateway.assembly.core:tar.gz:bin</include>
>   </includes>
> </dependencySet>
> This makes the filtering option essentially unusable, since I can't find a way to eliminate this top-level directory creation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira