Kenney Westerhof wrote: > On Wed, 24 Aug 2005, Brett Porter wrote: > >>I think this is reasonable, but I'd like to allow multiple sources >>(properties, and multiple files). The existence of the filtering element >>can be used to trigger it. > > > I don't think it's a good idea to specify the filter files at the > resource level (assuming the <filtering> below is a child element of > <resource>). Yes, the filtering is a child of the resource.
> Specifying tokens however is a good idea. Hmm, actually, I don't see a real difference between specifying tokens directly or "externalizing" them into a properties file. Why do you think that tokens are a good idea while files not? > > I think you should be able to use different filter properties files using > profiles. The resources plugin can check for the presence of all tokens > and bail if some are missing. So: > > <resource> > <filtering> > <filterTokens> > <token>tokenname</token> > <token>anothertokenname</token> > </filtertokens> > </filtering> > .... > </resource> > > Specifying the filter files themselves above is only nice if you use > the same token values in different resource files. However, that's not > the most common usecase for using filters: it's for building for different > environments. According to the m2 philosphy you should have different > projects, but it's not possible to filter resources from another project > (unless you use relative paths to resource dirs). So having profiles > with different filter files should solve this (that's what profiles > are for anyway). > Hmm, I agree with the profiles handling, but I think there are use cases where you want to use different property files for a single profile. As I said, using tokens directly in the pom or putting them in a properties file is the same thing, it's just a different location. Therefore I think it makes sense to directly specify property files for the resources in addition to possible tokens. But I don't insists on this, for now I'm happy if I can specify tokens for the filtering. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
