Thanks Stephen, these are good leads. I had seen both of these projects some time in the past, but hadn't strongly considered them.
A primary concern is reusing existing maven plugins. Ship seems focused on general script execution, no? I'm still left with getting a groovy script to execute a maven plugin. Due to differences in component resolution between plugins, maven itself is likely to be the only reliable container for a plugin to run within. The concept of invoker reminds me of a blog entry I read somewhere where an "n+1" project is used to distribute all the software. But unfortunately, that project would have to be tuned every time a new project is added. Still searching... Cheers, Brian On Jun 25, 2011, at 12:09 AM, Stephen Connolly wrote: > 1. have a look at the ship-maven-plugin (i wrote it, but i think it has some > good ideas for continuous delivery as well as delivery in general... i call > it ship to have a different term from deploy so as not to confuse the maven > lifecycle) > > 2. you might have some luck with, eg the maven-invoker-plugin, or at least > use maven-invoker from your own plugin... > > - Stephen > > --- > Sent from my Android phone, so random spelling mistakes, random nonsense > words and other nonsense are a direct result of using swype to type on the > screen > On 25 Jun 2011 07:57, "Brian Topping" <[email protected]> wrote: >> Hi all, >> >> I'm picking up a project that requires a configurable large scale > deployment, something on the order of five concurrent development branches > of HEAD, each with about five servers that the various projects in a branch > will need to deploy to. Ideally, everything will be contained in the Maven > build such that CI could deploy automatically and individuals with a > sufficiently robust settings.xml could deploy manually from a Maven > invocation. >> >> The servers that are being deployed to will require a mix of different > deployment strategies (one per packaging) and more than one artifact will > need to be deployed to each server over the course of a reactor build. > Closed-source m2 plugins have been developed for each of these package types > and are provided by the target container vendor. Each plugin is basically a > REST client that wouldn't be hard to rewrite, but it would be advantageous > to use the vendor's plugins. >> >> Having read > http://docs.codehaus.org/display/MAVEN/Dynamic+POM+Build+Sections, I set off > with the plan that executions might be added to a running build by a plugin > in the initialize phase. For instance, if an artifact A needed to be > deployed using plugin X to five separate machines for a branch, X would not > be statically configured in the POM with five separate executions (which get > transformed into entries in the goal queue), rather some plugin would be > developed to insert the five new goals at the right place in the goal queue > dynamically. >> >> But it turns out that m2 pre-generates the list of goals before the first > plugin runs, and in any case are not accessible from the mojo context, so > this appears to be impossible. I haven't had a chance to check if this is > still true in m3. >> >> I took a look at Cargo, and it would probably work if Deployer > implementations were developed, but again, local requirements strongly > prefer using the vendor's m2 plugins, and Cargo doesn't have a means to wrap > an m2 plugin in a Cargo Deployer for pretty obvious reasons. >> >> I can easily see that plugins could be configured in a parent build and > executions statically defined, one per target machine in each build that > needs a particular kind of deployment. This creates a lot of configuration > volume though, something I was hoping to avoid by creating named groups for > the servers and possibly storing them in LDAP. This is especially important > in the production cluster, where there are about 100 servers, and the > expansion of the POMs for all these servers would not be well-received > (merging the branches to HEAD prior to a release would be very tricky for > the POMs, besides just being unwieldy). >> >> It may be that I am missing something obvious, or it may be that Maven > isn't ideal for this job. Can anyone who's tried this before share their > thoughts on it? >> >> Kind regards, Brian >> --------------------------------------------------------------------- >> 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]
