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]
