Thanks for all the replies.. it has helped shape the decision i have made for our projects.
In the end this is what i did: - The gui, common and server projects get deployed as binary only jars to the nexus. They contain no configuration specific to any environment. It allows me to move the same jars through multiple environments based on external configuration. This conforms to the maven way. These projects have really light poms, describing mostly dependencies and where required extra build info (for example the common project i have generates google protocol buffers code via the maven-protoc-plugin). - I created a seperate project called myproject-build. This is a maven project but is really just a facade to my SCM repository. Theoretically it could be just a whole bunch of files checked in to the repo, but i like the power of mavens assemblies, sql execution plugins, filtering etc. so i use it with that intent. It only has one dependency and this is on the server project and by using the skip property on the deploy plugin i can prevent this project getting uploaded to the nexus. The other good thing about using maven to manage this is that i can still use the m2e plugin inside my IDE, so i can create a 'Run Application...' or Debug, profile locally, simply by setting the main class as my servers main class but on my my-project-build project! Releases are then built from the assemblies in the build project based on profiles which call filters that get put in my src/main/config directory (allows me to run locally). I know this wasn't the goal of maven, but perhaps in an upcoming version, more throught could be put into the multi environment support out of the box, rather than relying on organisations to come up with their own strategies. One big selling point on the idea above is that it works in any IDE that supports maven, but also works on my build server without the need for another configuration mechanism or scripting etc. It just all comes from maven's out of the box features. It also allows me to keep all my passwords and config settings in sync with each other as they are all in the one spot! With regards to production passwords, well they aren't stored anywhere developers know about. I simply use the filtering to put in something like "PASSWORD REQUIRED HERE" in the production build's filter so the support/release staff know where to apply their passwords (locations supplied in documentation to them). Thanks for all the ideas and i hope this idea helps anyone else looking for out of the box maven support for split binaries and configuration all coming out of maven -- View this message in context: http://maven.40175.n5.nabble.com/Maven-environment-configurations-tp4586719p4590211.html Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
