mkarg commented on issue #5: Parameter `fileMapper` for unpack path rewriting URL: https://github.com/apache/maven-dependency-plugin/pull/5#issuecomment-423752749 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. ;-)
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
