Right - this is a slice of the answer and I agree - the real heart of the matter is, where does the configuration live? In settings.xml? Profiles.xml? Filter files?
How can you reuse them in a deployment world where you're not using maven? I'd like to know how people are handling these things. > If you do get into the situation where you want to share properties > and settings in the original build and share them across teams, the > best solution is to use the dependency plugin to unpack an artifact so > that the information can be consolidated and deployed within that > artifact. 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? -----Original Message----- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 5:10 PM To: Maven Users List Subject: Re: Maven 'deploy' relationship to large-scale software deployment 2008/8/1 EJ Ciramella <[EMAIL PROTECTED]>: > This only hints at solutions to #2 below: > >> 2 - How does one deploy said generated application zip/tar file? >> There's nothing I can see supplied in any plugin to support large > scale >> deployments (say, six app servers, four web servers, a db server, a >> utils server and another half dozen or so third party servers). We've >> been using ant and an internally written shell script. > > Yes, we drop maven once the build is headed anywhere other than the > local machine - but even within this developer environment, how do you > share properties/configuration/etc across different applications without > massive copy/paste duplication? How does anyone build to support > multiple environments? Are you really rebuilding the ear with a > different configuration? Is your ear over say, 20 mb? > > Are people just NOT building this level of complexity within maven? > > Even if the configuration/profiles was pushed out into a "corporate" pom > (something outside of the general project structure), if/when that > changed, you'd have a million poms to update to point them to a new > parent version. Sorry, I was replying to the OP, I just hit the wrong box in gmail. I highly recommend externalised configuration wherever possible - that is to have the ear or more general artifact not have any knowledge of it's target deployment environment. The classic example of database connections, using JNDI can be managed in the server configuration by the deployer rather than built into the artifact. Another alternative, if the information must be within the artifact, is to post-process the artifact on deployment to put the appropriate settings in rather than deploying 6 versions to the repository. This is again separate deployment tooling that would be needed and the configuration for the target environments is managed along with it. If you do get into the situation where you want to share properties and settings in the original build and share them across teams, the best solution is to use the dependency plugin to unpack an artifact so that the information can be consolidated and deployed within that artifact. HTH, Brett --------------------------------------------------------------------- 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]
