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. -----Original Message----- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 4:48 PM To: Maven Users List Subject: Re: Maven 'deploy' relationship to large-scale software deployment I think you'll find that Maven itself stops at the repository. So the best thing to do is to use tools that can take artifacts from the repository and deploy them. There are lots of other solutions around for doing this sort of thing beyond that point and they specialise in handling the new set of problems it brings. I've generally found those doing the deployment are very separate from the rest of the development team and often have their own chosen set of tooling. You could use Maven itself to do this - though I'm not aware of any plugins that focus on this. While Cargo is generally used for test setups, it could serve this purpose as well, but it's mostly a space for a new piece of work. Cheers, Brett 2008/8/1 EJ Ciramella <[EMAIL PROTECTED]>: > No, I don't understand how to do it either. I just stepped out of a > meeting where we were discussing how we can deploy the same set of > applications (which _some_ share properties) across 10 - 15 different > environments. Some environments have different configurations, some are > carbon copies. > > There doesn't seem to be any maven solution to either/all of these > problems: > > 1 - Where does a property go (say db connection string) that's shared > between different applications such that there isn't duplication? No > one wants to have to search/replace values in various profiles.xml or > pom.xml files (I don't mind, but others in the organization have > objected). Here, since there are so many applications pointed at the > same db, that could be a dozen or so files that have the same db string. > > 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 a internally written shell script. > > 3 - How do people configure these things? I've heard every answer from > "we generate a zipped/tarred up application file for every environment" > to "we use installshield and don't have to worry" and everything in > between. We have in one environment alone, 6 jboss servers for ONE > application. That ear that gets deployed there (and all it's supporting > files) even compressed in a zip takes close to 200 mb. I'm not about to > generate 1200 mb worth of ear files with each build (sometimes there's > three or more built in a single day). > > I feel like either there are different terms to describe these things or > no one is doing anything to this scale. > > I'd love some feedback/suggestions as to how others are doing this. > > -----Original Message----- > From: stug23 [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 31, 2008 10:25 AM > To: users@maven.apache.org > Subject: Re: Maven 'deploy' relationship to large-scale software > deployment > > > Am I alone in needing to understand how Maven relates to large-scale > software > deployment? > > :confused: > > > stug23 wrote: >> >> Maven has its own notion of 'deploying' a software artifact to a Maven >> repository. And there are quite a number of 'out of band' Maven > plugins >> such as Cargo that can remotely deploy a war file to a running web >> container. >> >> My question centers on how Maven relates to situations where once a >> software system has been built and tested, the software components > then >> need to be globally distributed to many sites. This notion of > 'deploying' >> would appear to be quite different than the one embodied in Maven's > deploy >> goal. >> >> What experiences have developers here had in leveraging Maven for >> large-scale deployments? When did you stop using Maven and resort to >> other solutions for deploying bundled software to many distributed > sites? >> Or were you able to use Maven for your large-scale software deployment >> right out to the sites? >> >> I would be interested in comments on how others have dealt with this > part >> of software deployment. My use case involves distributing 10s of SOA >> services and web applications to many sites. >> > > -- > View this message in context: > http://www.nabble.com/Maven-%27deploy%27-relationship-to-large-scale-sof > tware-deployment-tp18717756p18755789.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] > > > --------------------------------------------------------------------- > 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]
