Affects Version/s: None
Fix Version/s: None
Number of attachments :
The current resource filtering has to be configured at the resource plugin configuration. This issue is about making resource filtering more user-friendly.
There are the following requirements:
1) being able to split resources up into two groups: the filtered-on-copy
group and the 'just-copy' group.
2) being able to specify multiple properties files / having a default file
so users can override. Much like project.properties/build.properties
3) being able to specify different filter properties using profiles
The last item 3) is already working, so this is about 1) and 2).
What about adding the following XML to the resource section of the POM:
And this configuration to the resource plugin
From the following list a) and b) address item 1) while c) addresses item 2):
a) As soon as a filtering section is available on a resource, it is filtered.
b) Usually you have in a single resource directory resources that you want to filter and resources that shouldn't be filtered like images etc. One solution to address this is to specify two resource sets in the POM with different include and exlucde filters and turn on/off filtering accordingly.
I think a more elegant way is to say, this is my resource set and filter only these files in this resource set. That's why I added the filterIncludes and filterExcludes section. We can also define default filterExcludes like images etc. On the one hand this is imho a more natural way of defining filtering and on the other hand, this should increase performance. The resource tree has only to be scanned once. With two resources, the tree is scanned twice. Especially if you have big resource trees (e.g. for webapps) this should increase performance noticeably.
c) You can specify several property files at the resource plugin. This files are read in the order of appearance and if a token is defined twice, the last definition read wins. In addition you can set the failOnError flag on a property file, so if this file is missing no error occurs.
I could imagine these optional additions:
4) Defining the tokens in the pom so the plugin
could check which ones are missing and you have an overview of
all the configuration settings used in all the resource files
(the latter being more important).
So, we could add this XML to the filtering section in the POM:
If the section is missing all tokens are replaced by default.
5) Define properties directly without a property file.
We could add this to the resource plugin configuration: