[ http://jira.codehaus.org/browse/MNG-788?page=comments#action_45352 ]
Brett Porter commented on MNG-788: ---------------------------------- agreed, and done. anything that is backwards compat with m1 is a good thing :) > Proposal for improved resource filtering > ---------------------------------------- > > Key: MNG-788 > URL: http://jira.codehaus.org/browse/MNG-788 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Versions: 2.0-beta-1 > Reporter: Carsten Ziegeler > Fix For: 2.0-beta-2 > > > 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 > in maven1. > 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: > <filtering> > <filterIncludes/> > <filterExcludes/> > </filtering> > And this configuration to the resource plugin > <configuration> > <filterPropertyFiles> > <filterPropertyFile>src/build.properties.sample</filterPropertyFile> > <filterPropertyFile > failOnError="false">src/build.properties</filterPropertyFile> > </filterProptertyFiles> > </configuration> > 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: > <filterTokens> > <token>tokenname</token> > <token>anothertokenname</token> > </filtertokens> > 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: > <filterProperties> > <filterProperty> > <name>aToken</name> > <value>someValue</value> > </filterProperty> > ... > </filterProperties> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
