On Wed, 24 Aug 2005, Carsten Ziegeler wrote:
The difference is that you only define the _tokens_ in the pom, not their values. This indicates which tokens are used by the resource files. Specifying both key and value pairs in the pom doesn't allow for users of the project to specify their own values without modifying the pom itself. You could specify a 'src/main/conf/config.properties' in the pom, and supply a sample file 'src/main/conf/config.properties.sample' (or even in the current dir) that users have copy & edit to fill in their specific settings (smtp servers, hostname, port, location of tomcat/j2ee containers etc..) That way even in a big team each teammember should configure their test/build environment using the sample file (if this is needed). I used to work on projects using this mechanism (using ant), having a build-dev.properties, build-live.properties, build-test.properties for different environments, running and with -Dbuild=dev would load that set of properties. (as you can see, my main concern in specifying properties file is for use in different environments, not centralizing the token data per se). -- Kenney > 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] > -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
