Tim Holloway wrote:Actually, your definition of "one war" and mine don't seem to be the same. I, too, build only one war, but it's the same war for development, test, and production. Bit-for-bit, byte-for-byte. Build one WAR file and deploy it to whichever server. There's no per-server properties files inside the WAR. And no danger of accidentally deploying a test WAR on the production server, since the test WAR is the production WAR. The attributes that make a WAR a "test" war are all injected from external sources.
I think you actually already know about Maven profiles, but you're mistaken about one thing. You most definitely can specify more than one profile on a build, and that can be useful when you have to do things like say, build a WebSphere WAR for iSeries when you also provide a WebLogic WAR for Linux. Mix and match OS's and server environments using combinations of profiles.
Incidentally, I find this annoying, but profiles do not override mainstream resources. If you want a custom web.xml, for example, you can't provide a default web.xml in the src/main/webapp or it will take precedence over a profile-specific src/tomcat/webapp version of the same file.
Hi Tim
Thanks for your reply.
Sorry if my original post wasn't clear. We actually do have the same deployment scenario - we only compile 1 single binary war, and all environment-specific configuration is kept outside, and referenced or injected at runtime.
I will research the use of multiple profiles more, but it seems contradictory at first. I could see how you can override/cascade properties from multiple profiles into one set of valid properties, but how would the build know to create a different asset for each, rather than just one that has a combination of the overridden properties?
I have also begun to explore using "executions" to bind the resource:resource goal multiple times to the process-resources phase.
This is almost working except for 2 things:
1. the build still executes the default "default-resources" execution, which copies all of the resources to target/classes. (minor, i'm sure there is a way to turn this off)
2. None of the properties in dev.properties are being resolved in the resulting resource after it's copied. Seems like this may be a bug in maven:
http://jira.codehaus.org/browse/MRESOURCES-77