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. ;-) [ Full content available at: https://github.com/apache/maven-dependency-plugin/pull/5 ] This message was relayed via gitbox.apache.org for [email protected]
