Alternatively a method we used was to use tokens like @dbdriver@
in the tr.props file and have a seperate build.properties file outside of cvs, e.g. dbdriver=Oracle Then use ant to filter the tr.props fill and fill in the tokens from the build.props at build time. This is also useful for different development/live builds. Gareth > -----Original Message----- > From: Skip Walker [mailto:[EMAIL PROTECTED]] > Sent: 26 March 2002 03:19 > To: 'Turbine Users List' > Subject: RE: config layers > > > > Simple! > > Cut the relevant database properties out of TR.props and put them into > another file, say DB.properties. > > Add the following line to the TR.props file: > > include=DB.properties > > > Use a different DB.properties file depending on your needed configuration. > > Skip > > > > -----Original Message----- > > From: Jesse Chen [mailto:[EMAIL PROTECTED]] > > Sent: Monday, March 25, 2002 9:03 PM > > To: Turbine Users List > > Subject: config layers > > > > > > Hi, > > > > We have 2 teams that are currently developing on a shared > > codebase using > > Turbine2.1 in CVS in opposite parts of the world. > > Unfortunately, the DB > > settings need to be different for each team due to network > > infrastructure > > issues. > > > > I was wondering if there was an elegant way to point the > > Database Settings > > properties in TurbineResources.properties to an alternate > > properties file > > (ie: conf/localDev.properties) without having to extend the > > TurbineResource > > classes? This way, we can share config settings on everything > > else except > > the DB settings, which can be managed locally. > > > > thx, > > > > J > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
