My current build environment sucks in a variety of different property files that specify various database locations, deployment properties and so on.
They are both project specific and user specific. ${basedir}/project.properties and ${user.home}/build.properties don't work for this. I think ${basedir}/build.properties was design for this, but then you run into the next problem.
The next point is that some of these quite often duplicated between users and different subprojects. The best example is a SOAP service we use. There is a testing server that all our dev/stage apps should hit, and a production one for our production apps. There is a few config properties, but each dev user doesn't want to have to configure them all in a build.properties: instead, they just set soap.server=test (or prod), and then I do this:
<filters>
<file>${basedir}/../common/soap-${soap.server}.properties</file>
</filters>
Maybe I'm missing something - I'd love to hear it. That way we could agree on just the standard properties files. However, this needs to be implemented anyway so is within the scope of the issue.
Thanks, Brett
Michal Maczka wrote:
I also think build.properties, project.properties and driver/default.properties should be included by default when filtering is enabled.
If we have them included - why to bother to use another set of properties files? Isn't that just enough?
mm
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Web Developer f2 network ~ everything essential 02 8596 4437
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
