[
https://issues.apache.org/jira/browse/MASSEMBLY-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Plamen Totev updated MASSEMBLY-803:
-----------------------------------
Description:
Hi,
Currently when using {{dependencySets}} with {{unpack}} set to {{true}}, there
is no way to set the output file names mapping. As plexus-io supports file
names mapping, I think it will be relatively easy to add such option.
Consider the following scenario. You want to distribute tomcat as part of your
product. You could add something like that;
{code:xml}
<dependencySets>
<dependencySet>
<includes>
<include>org.apache.tomcat:tomcat:8.0.33:zip</include>
</includes>
<unpack>true</unpack>
</dependencySet>
</dependencySets>
{code}
So far so good. But the zip archive contains {{apache-tomcat-8.0.33}} as root
folder.What if I want to distribute it under {{tomcat}}? There is no way(AFAIK)
to just extract sub folder of the archive. Of course there is {{<excludes>}}
tag but the matched files will be still under {{apache-tomcat-8.0.33/...}}
The use of {{FileMapper}} for example may strip the root folder (the
{{RegExpFileMapper}} seems like a perfect candidate).
What do you think about such feature?
p.s. Not quite sure where is the proper place to discuss such improvements
requests - here or in the mailing list. So excuse me if this is not the proper
place.
was:
Hi,
Currently when using dependencySets with unpack set to true there is no way to
set the output file names mapping. As plexus-io supports file names mapping I
think it will be relatively easy to add such option.
Consider the following scenario. You want to distribute tomcat as part of your
product. You could add something like that;
{code:xml}
<dependencySets>
<dependencySet>
<includes>
<include>org.apache.tomcat:tomcat:8.0.33:zip</include>
</includes>
<unpack>true</unpack>
</dependencySet>
</dependencySets>
{code}
So far so good. But the zip archive contains {{apache-tomcat-8.0.33}} as root
folder. But what if I want to distribute it under tomcat? there is no way to
just extract sub folder of the archive. Of course there is {{<excludes>}} tag
but the matched files will be still under {{apache-tomcat-8.0.33/...}}
The use of FileMapper for example may strip the root folder (the
RegExpFileMapper seems like a perfect candidate).
What do you think about such feature?
p.s. Not quite sure where is the proper place to discuss such improvements
requests - here or in the mailing list. So excuse me if this is not the proper
place.
> Add file name mapping option when extracting dependencies
> ---------------------------------------------------------
>
> Key: MASSEMBLY-803
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-803
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: dependencySet, moduleSet
> Reporter: Plamen Totev
> Priority: Minor
>
> Hi,
> Currently when using {{dependencySets}} with {{unpack}} set to {{true}},
> there is no way to set the output file names mapping. As plexus-io supports
> file names mapping, I think it will be relatively easy to add such option.
> Consider the following scenario. You want to distribute tomcat as part of
> your product. You could add something like that;
> {code:xml}
> <dependencySets>
> <dependencySet>
> <includes>
> <include>org.apache.tomcat:tomcat:8.0.33:zip</include>
> </includes>
> <unpack>true</unpack>
> </dependencySet>
> </dependencySets>
> {code}
> So far so good. But the zip archive contains {{apache-tomcat-8.0.33}} as root
> folder.What if I want to distribute it under {{tomcat}}? There is no
> way(AFAIK) to just extract sub folder of the archive. Of course there is
> {{<excludes>}} tag but the matched files will be still under
> {{apache-tomcat-8.0.33/...}}
> The use of {{FileMapper}} for example may strip the root folder (the
> {{RegExpFileMapper}} seems like a perfect candidate).
> What do you think about such feature?
> p.s. Not quite sure where is the proper place to discuss such improvements
> requests - here or in the mailing list. So excuse me if this is not the
> proper place.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
