So say you're deploying to jetty - AND you're deploying a daemon process locally AND you're deploying to jboss (a separate webapp).
Where do you store that configuration such that its centralized and you're not updating a million profiles (or profiles.xml files)? Settings.xml? I find it slightly impractical to have local builds configure one way and deployments use a totally different configuration process. I think that opens the door to the "it works on my machine" type deployment error. -----Original Message----- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2008 11:17 AM To: Maven Users List Subject: Re: Maven 'deploy' relationship to large-scale software deployment Say you are deploying to Jetty , and you configure all your database settings via jetty.xml that is part of the installation. I'm just saying that while it can help, that's typically out of the scope of Maven so what ever tool you choose (if any at all) for that env should manage and version the configuration. It could be as simple as checking out the configuration files from subversion and some scripts for restarting an individual server and updating the web application, or an extensive automated configuration management solution. - Brett 2008/8/2 EJ Ciramella <[EMAIL PROTECTED]>: >> If you do separate the configuration from the build, then how you > manage it is really dependant on how others deploy the application. > > Can you clarify this? > > -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 31, 2008 6:03 PM > To: Maven Users List > Subject: Re: Maven 'deploy' relationship to large-scale software > deployment > > 2008/8/1 EJ Ciramella <[EMAIL PROTECTED]>: >> I looked into this, but that wouldn't work. If you unpack say, a >> profiles.xml file, it's too late in the build sequence. You'd need to >> unpack, stop, start up your build again. And if you use a filter > file, >> you can't override those properties from your settings.xml. >> >> Is there some other magic I'm not seeing here? > > I wasn't suggesting the unpacking of these files - it is very unlikely > settings or profiles would contain application configuration. They are > the environment for the build, not the environment for the deployment. > > the artifact can be used for filter files, resource descriptors, or > other configuration files built into the artifact - but again, this > gets into the situation where you either need to build for multiple > targets or post-process the artifacts, which often isn't ideal. The > technique is much better for sharing non-environmental configuration > among multiple applications instead. > > If you do separate the configuration from the build, then how you > manage it is really dependant on how others deploy the application. > > Cheers, > Brett > > -- > Brett Porter > Blog: http://blogs.exist.com/bporter/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Brett Porter Blog: http://blogs.exist.com/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
