You don't even need a plugin. Instead of calling maven directly, your CI could call a script which calls the maven commands seperate. So your CI only need call the one script. One of my collegues does exactly that.
You could also use the release plugin. --- Todd Thiessen > -----Original Message----- > From: David Hoffer [mailto:[email protected]] > Sent: Friday, April 17, 2009 12:48 PM > To: Maven Users List > Subject: Re: Multi-module build is not building with current > module source code > > Yes, I'm sure we call: > > mvn clean deploy site-deploy > > I too figured site-deploy would happen after the deploy so > all would be well. > > I have not written a plugin before, I'm not sure I'd know how > to do this. > > I can't easily change my build to do this in separate steps, i.e. > > mvn clean deploy > mvn site-deploy > > Because our CI server doesn't support running two separate > command lines when using maven, I would loose all maven > support if I did this. (If someone could point out how to > write a maven plugin that would perform the two steps, I > would be interested in trying this.) > > I am using maven 2.1. > > -Dave > > > On Fri, Apr 17, 2009 at 10:38 AM, Stephen Connolly < > [email protected]> wrote: > > > Ahhhhh > > > > OK, that explains some things, but I'm not sure how you go about > > fixing them ;-) > > > > I suspect some of your site reports are forking a build... > the forked > > build will not have reference to the reactor artifacts from > the main > > build, so as a result will pull the version from the local > > repository/remote repository which will be the previous > version and so > > fail the build. > > > > if you disabled your remote repository and purged > dependencies again > > you should be able to reproduce the failure with the > goal(s) you are > > providing to the CI server... thereby at least confirming > that this is > > a forked build by site problem (since you'd have your build log) > > > > Also are you sure it's > > > > clean deploy site-deploy > > > > and not > > > > clean site-deploy deploy > > > > my understanding is that lifecycle phases are invoked in > the order in > > which they occur. > > > > you might be able to cheat by writing a simple aggregator > plugin that > > does nothing and invoking that aggregator goal in between > deploy and > > site-deploy... since a build plan for such would force the > deploy to > > have completed on everything before starting the site-deploy... > > > > (I mention build plans... but they may be a 3.0 feature) > > > > what version of Maven is this also... I'm hoping this is > not a 2.1.0 > > regression > > > > -Stephen > > > > 2009/4/17 David Hoffer <[email protected]>: > > > Your replies do make sense to me, I have had this problem with > > > renaming artifacts, etc but I think to really find all missed > > > changes you also > > would > > > need to purge these from your corporate repo. > > > > > > Okay I have more data on why our CI builds fail. (I'm > prepared for > > > a > > 'your > > > doing it wrong' type of answer). > > > > > > On our CI system we want a complete site report in addition to the > > regular > > > clean & deploy goals so our build command is: > > > mvn clean deploy site-deploy > > > > > > The problem is the site-deploy. If we remove this then > we get the > > > normal build process where each module is built, installed and > > > deployed in order for each module. > > > > > > When we add the site-deploy it doesn't do this, rather it > builds the > > source > > > for each module WITHOUT doing an install and/or deploy first. So > > > the site-deploy seems to be taking over and saying I need > to do my > > > tasks > > first > > > then you can do the normal build. > > > > > > How should I be doing this? I.e. How can I get the site to be > > > generated > > and > > > deployed AFTER the normal clean deploy goals? I don't want site > > generation > > > to be done separately on a different trigger because its > important > > > that > > the > > > site be based on the artifacts generated during the deploy phase. > > > > > > Hopefully there is a simple fix for this? > > > > > > -Dave > > > > > > > > > > > > > > > On Fri, Apr 17, 2009 at 8:16 AM, Todd Thiessen > <[email protected]> > > wrote: > > > > > >> > So how then does one know when they have to purge the local > > >> > repository? Having rules where you sometimes need to and > > >> > sometimes don't is really hard to live with. Perhaps you can > > >> > clarify the rules? > > >> > > >> I can provide a bit of clarify here. You could have a problem if > > >> you changed the artifactId, groupId or version of > anything in your project. > > >> Maven would install a new copy of this artifact in your > local and > > >> if you happen to forget to update all references to this > > >> dependency, your code will still build and compile file, but you > > >> may get unexected runtime problems. If you purge your > local, your build will properly fail. > > >> > > >> > And if it's important why isn't it done by default? > > >> > > >> This is a good question which I am not qualitfied to > answer. I have > > >> been tempted to add to the clean phase a goal which also deletes > > >> the artifact from the local repo (although this still > isn't sufficient). > > >> > > >> > ------------------------------------------------------------------- > > >> -- 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] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
