[MDEP-628] Parameter fileMappers for unpack path rewriting

[mkarg]

Solving MDEP-628.

The new parameter fileMappers (default: null) can be set to an implementation of the org.codehaus.plexus.components.io.filemappers.FileMapper interface to rewrite the target path of each unpacked file.

This is useful in case prefixes of target files names within the target directory shall be added (using PrefixFileMapper), changed or omitted (using RegExpFileMapper).

[plamentotev]

What is the use case that this feature covers? I just wonder if you need complex and powerful way to organize files, isn't assembly plugin (with dir archive) more suitable?

[mkarg]

Believe me, it was the perfectly correct choice to provide exactly this solution, and we really need this complete freedom of mapping! ;-)

First of all, the assembly plugin has the same problem: It cannot freely rewrite target paths, but this is what we actually solved. Second, as we do not want to create assemblies at all, it would simply be a misuse; what we actually want is to unpack dependencies, so the correct way is to dependency:unpack and nothing else.

In cour case, what we needed is to invoke external tools as part of our build process which expects a particular directory hierarchy. The source of the files in that hierarchy come from several external dependencies (ZIP files), i. e. their content is not under our control. The problem is: The tools expect a completely different hierarchy than the one found in the ZIPs. For example, each ZIP has some kinde of parent folders structure inside, but the tool wants a different parent structure:

Dependency ZIP A:
/a/b/C

Dependency ZIP B:
/d/e/F

Tool can only process *exactly this* folder structure:
/u/v/w/C
/x/y/z/F

The solution of extending the dependency plugin is clean and straightforward: We now can simply add the RegExMapper config within each <ArtifactItem> in the unpack config.

So to sum up: It was the perfectly correct way to fork and extend the dependecy plugin. Everything else would just be a bad hack. ;-)

[plamentotev]

Yes, you're right that in such case it does make sense to use the dependency plugin instead of the assembly plugin.

[mkarg]

@plamentotev Review please. :-)

[plamentotev]

@mkarg I don't have commit rights and I'm not very familiar with the plugin code base so it would be better if somebody else reviews it. I've asked about this pull request because recently there was similar contribution to Plexus Archiver about file mappers and I was curious it it is the same use case (but it turned out to be a different one). Sorry for bringing a bit of noise in your pull request :)

…

On Mon, Sep 24, 2018 at 5:59 PM Markus KARG ***@***.***> wrote: @plamentotev Review please. :-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[mkarg]

Could someone else review please? :-)

[plamentotev]

@mkarg Plexus Archiver 3.7.0 is now released so you can update the dependency.

[mkarg]

@plamentotev Thanks for the info! I pushed 65e7ff7 so MDEP has no SNAPSHOT dependency now. :-)

[mkarg]

@khmarbaise @hboutemy I would be happy if you could review this PR and consider for merging. :-)

[mkarg]

@khmarbaise @hboutemy @rfscholte What do I have to do to make you review my implementation of MDEP-628? You are neither reviewing it nor answering to discussions in this tracker nor to emails. So what am I supposed to do to get it reviewed?

[rfscholte]

A ping like this helps. I've had a look at the patch, but I am missing a test to confirm this feature. Probably easiest solved by providing an Integration Test under src/it/projects, executed with mvn verify -Prun-its

[mkarg]

@rfscholte Amended existing integration test to verify mapping works well, see d47a4ab.

[rfscholte]

Could you copy the unpack-dependencies instead of adjusting it? We need to ensure that the default 1:1 extraction keeps working as expected.

[mkarg]

@rfscholte Done. :-)

[mkarg]

@rfscholte Thanks! :-) 🎉