What I'm doing at eXo to manage such cascading releases without having a huge manual process to keep everything up-to-date is that I have a profile that allow to activate a group with all staging repositories. Jenkins is allowed to take artifacts from this staging group BUT it has to delete all local repositories every night. Thus if a project has to republish something in staging then Jenkins will be up-to-date at the maximum after 24h It's far from beeing perfect but at least there is no/few management cost on jenkins side and we can chain releases with few maven settings.
I don't know if we could have a similar setup here. Arnaud On Tue, Nov 29, 2011 at 3:01 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > I'd just vote on both at the same time... jenkins can fail if it wants... > or I can see about getting Apache a license for skippy (a.k.a. CloudBee's > Skip Builds plugin) > > On 29 November 2011 13:22, Benson Margulies <bimargul...@gmail.com> wrote: > > > This morning, I considered the following: > > > > 1) Stage maven-common-filters 1.4 and call a vote > > > > 2) Make a settings.xml for myself that included the staging repo. > > > > 3) Update maven-assembly-plugin to use maven-common-filters 1.4, > > building using the settings.xml. > > > > 4) stage maven-assembly-plugin and call a vote, explaining how to > > duplicate the configuration for testing. > > > > Then I realized that the jenkins builds would break. > > > > Then I realized that, if we have an up-to-date enough Jenkins, I could > > temporarily add the same settings.xml to the job. > > > > WDYT? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
