Maven multi-module project - how to run an operation after all submodules have finished

I have a multi module maven project and I'd like to be able to run an operation (antrun) after all submodules have finished their execution.

In my projects I build RPMs from each sub-module and in the deploy phase I copy the RPMs (by ssh) to an RPM repository.

The RPM repo requires me to run a createdb command after adding new RPMs so that it can index them.

So I have an antrun that actually runs scp and copies the RPMs to the repo. It runs for each submodule that actually produces an RPM and is hooked to the maven deplo开发者_开发知识库y phase. What I can do is after each scp run the createrepo command but that'd be wasteful, I have more than 10 submodules and each createrepo takes about a minute so I'll be wasting precious build time.

What I'd like to do is after all submodules have finished, then run the createrepo. Once.

My first attempt was to hook the antrun which calls the createrepo command to the parent pom's (the super-pom) deploy phase. I did that and the problem was that the parent's deploy phase runs before the submodules' deploy phase. I wanted it to run after

I can't attach the createrepo antrun to any other later phase since the deploy phase is the last in the lifecycle.

So my question is: Is there a way to run a "cleanup" antrun or a plugin in general that'll get executed once, after all build operations of all submodules have ended successfully?

A hack around it would be to create yet another submodule and make sure it's last by making it dependent on all other modules and run the createrepo from this module's deploy phase. But that's ugly and hard to maintain. I prefer a cleaner solution.

Thanks

Maven version is 2.2.1

I'm not so sure that your final suggestion of creating a dedicated module dependent on all others is so ugly. After all, it is leveraging Maven's dependency management. You can name it in a very obvious manner to make it clear to maintainers what is going on and it will fit in nicely with the overall build process of the project.

Why not put it in place and see how well it works for you? Remember that working code beats beautiful but non-working code every time.

I'm using solution that's separating building and packaging from publishing stuff. As we are using Jenkins, every build invokes publish job which handle's also createrepo stuff, and even nicer thing is that Jenkins lets you also run this publish job in paralel.

What was tricky is that actually during createrepo phase if two jobs run in exactly same moment of course one is going to fail, as they can't do same operation in same folder on same set of files. However, I implemented flock here just for createrepo phase, and now all jobs are running really in paralel plus three publishes in paralel as well were tested, but we are using two due to some other decisions.

However, using this approach, we lowered total build time from 1.5h to 15 minutes in total for twenty+ builds.