DependencySet unpackOptions 'filtered' causes unpack not to work

In 2.2, if I change <filtered> from true to false, the original behavior returns--the files from the dependent archive are not filtered (as expected), but are correctly exploded to the right places, and no extra directory with the same name as the archive is created.

BTW, the archive directory that is created when <filtered> is true is really com.kaazing.gateway.assembly.core-3.1.0.26-SNAPSHOT-bin.tar.gz.

To reproduce the bug, unzip this file. You will have two maven projects (com.kaazing.gateway.fake1 and com.kaazing.gateway.fake2). Run 'mvn install' on fake1. Run 'mvn install' on fake2. Take the result of the 'fake2' install (see fake2/target/com.kaazing.gateway.fake2-1.1.1.1-SNAPSHOT-bin.tar.gz) and unzip and untar it. You will end up with a file (FAKE2_README.txt) and a directory (com.kaazing.gateway.fake1-1.1.1.1-SNAPSHOT-bin.tar.gz.) Notice that inside the directory is the file README.txt, and in that file you will see

product: Foobar
version: 1.1

If you then go into fake2/src/main/assembly/unix-bin.xml (the assembly file) and change <filtered>true</filtered> to <filtered>false</filtered> and rerun 'mvn install' for the project and untar and unzip the tar.gz file, you'll see that there are only two files (FAKE2_README.txt and README.txt), and no directory. Notice that in this case, the file README.txt now says

product: $

version: $

That's the bug--if <filtered>true</filtered>, we get the extra diretory, which contains the filtered version of the dependent file README.txt. If <filtered>false</filtered>, there is no extra directory, but no filtering, either.

One other comment. When filtered is true for the example, the following comes out during the build:

[INFO] Expanding: /home/combs/.m2/repository/com/kaazing/gateway/core/com.kaazing.gateway.fake1/1.1.1.1-SNAPSHOT/com.kaazing.gateway.fake1-1.1.1.1-SNAPSHOT-bin.tar.gz into /home/combs/dev/trunk/core_assembly_reorg/com.kaazing.gateway.fake2/target/assembly/work/com.kaazing.gateway.core_com.kaazing.gateway.fake1_1.1.1.1-SNAPSHOT_bin.tar.gz

It appears that the work directory (com.kaazing.gateway...) is being copied completely into the final result, rather than just the contents of that work directory. I assume this is the real bug.

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 $

-$

$

.$

, 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

I tried setting <outputFileNameMapping></outputFileNameMapping>, and while it results in the right data for the test case, if the test pulls in an archive (e.g. JAR file) from inside the .tar.gz, the structure of that archive is then messed up (the size is wrong, it seems to have malformed content, etc.) So that possible workaround isn't valid.

I hit the wall with this bug too. I tried using <outputFileNameMapping></outputFileNameMapping> workaround for a single file and it helps for time being. I'll see if I can trace down the code if I have some time. Thanks Dave.

I met also this inconsistent behavior.