I've been putting assorted .properties files in the WEB-INF/classes directory, and it works fine.
But, I've checked in these files into SVN, and when a user does a checkout, they get the "standard" versions. And that may not be where we want to get them, or where they should be.
The problem is that I put lots of stuff in the properties, such as host name for SMTP servers, the Host and URL for JDBC, usernames for the "from" field of outgoing email notices, etc. When I'm developing, I usually want to use a non-production set of values. And I can see that the marketing folks might want a copy on their laptops to show in demos. Clearly "production" wants real values.
What's a clean way to handle this?
Bear Bibeault wrote:I keep mine in a folder in the source tree and copy them to classes folder as part of the ant build.
But aren't all the files and folders in your source tree checked into SVN?
I was thinking of some hack where I look for a magic enviroment variable, something like PAT_CONFIG_HOME, and if its there, read from there, else let
the usual WAR/JAR rules hold. This feels like a hack.
Bear Bibeault wrote:So you don't want the deployed version to be in svn?
My scenario allows local developers to keep their private versions in the classes folder without svn issues. The "official" version is what is in svn, and is copied into the war file for deployment.
Of course, I want to have everything in svn, so I can install an OS, and svn, and pull everything out of the repository. And then a miracle occurs.
Perhaps I don't understand your approach. If the ant script is in svn, like mine is using netbeans, then the usual clean and build will get the usual "production" results.
Perhaps if you explained a bit more?
I usually end up with a hostname-based solution and/or a system property name-based one, either home-brewed or through a Spring-based PropertyPlaceholderConfigurator extension. We've always checked in developer-/host-specific files, although sometimes we've ended up with "local.properties"-like files that aren't under version control. I try to avoid that when possible.
During a build, the "official" versions become part of the war file for deployment.