> @Doug What you said is exactly what I'm talking about. I WANT to externalize > my configuration, and am almost set up to have it > completely external. My problem has been figuring out how to get the external > properties back into the WAR. For this, I'll check > how powerful these overlays that Matt mentioned are.
The thing is that you shouldn't get the config file (e.g. a properties file) back into the war. Instead, your code should read the config file from the classpath and then you just need to have the config file available on the classpath in runtime. This is supported by app servers etc by having this file in a config folder external to the deployables. A similar solution is to read the configurations from JNDI. Similar in that sense that it is external to your deployable archive. /Anders > > I DON'T want to couple database credentials etc. with my source code. I would > only put a template properties file in the source, with directions for > deployment. > > One idea is to have my xml files try to be more dynamic. For example I could > guide the configuration at runtime based on environment variables(I saw this > idea on-line somewhere). Environment variables are usually available as xml > properties. I could throw my external properties files into the > $CATALINA_BASE/lib directory and point to different files as I need them at > runtime. Does this sound reasonable to everyone? > > Thanks for all the ideas. > > On Aug 3, 2012, at 12:16 PM, Ron Wheeler wrote: > >> On 03/08/2012 12:04 PM, Jared Hall wrote: >>> I would like to be able to modify the contents of a WAR file. >>> >>> Goal: I would like to be in a directory with my WAR and a pom.xml. When I >>> type 'maven configure', I would like maven to apply a filter to some of the >>> files in the war, and then leave behind the exact same WAR, with the >>> filters applied. I don't need to compile any files, I just need to apply >>> some filters to some files that are already in a WAR. >>> >>> The motivation for this is that I compile something that is still >>> un-configured. I throw the war into my test environment and configure it. >>> If it passes, I graduate it to production and re-configure it. >>> >>> Note: I don't care whether or not I use Maven or something like a scripting >>> language to accomplish this. The end goal is what I described above, one >>> typed command that reconfigures the WAR. I thought Maven might be able to >>> do most of the leg-work for me. >>> >>> Any help is appreciated, thanks. >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >> Maven is not a scripting tool. >> It has very definite ideas about how software gets built and this is not >> really in line with its ideas. >> In dealing with Maven, you have to conform to its process or you will >> have a miserable life until you submit. >> "Resistance is futile" is your best mantra when planning to do battle >> with Maven. >> Stop before you start. >> >> Try Ant. >> It is the Border Collie of Java tools and wants to do whatever you want >> to do. >> It has no preconceived ideas about "Best Practices". >> >> Ron >> >> -- >> Ron Wheeler >> President >> Artifact Software Inc >> email: rwhee...@artifact-software.com >> skype: ronaldmwheeler >> phone: 866-970-2435, ext 102 >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
