Hi Martin, Yes, as you have already noticed there are some problems when genersting a Maven site with Maven 3. Looking for a suitable work-around I'd like to ask why you run 'mvn site' ?
Unless you want to view your own community created content, there are other ways to to things on a CI server that might work for you. At my dayjob we never run 'mvn site' on our projects on Jenkins, except for the developer handbook (which is a pure site project). If you want reports on the status of yuor code there are other ways. For example, if you want torun FindBugs and checkstyle on your code on Jenkins, you can use 'mvn verify findbugs:findbugs checkstyle:checkstyle' instead, and then use the Jenkins plugins for FindBugs and Checkstyle to render reports in Jenkins. This has the added benefit of giving you graphs over time for these tools. -- Dennis Lundberg Den 13 apr 2014 22:07 skrev "Martin Desruisseaux" < martin.desruisse...@geomatys.fr>: > Hello all > > An other aspect which may be worth to explore for reducing resource > consumption is the way we use or configure Maven. A few weeks ago, > executing "mvn clean install deploy site" on Apache SIS with Maven 3.1 > apparently trigged compilation of all source code 18 times. It may not > be Maven fault - I suspect some interactions between plugins, not all of > them developed at Apache. The situation seems to improve with Maven 3.2 > (still need to confirm). > > Martin > > > Le 13/04/14 15:49, Dennis Lundberg a écrit : > > Hi all, > > > > Like Hervé I feel that the current state of Jenkins at the ASF is not > > good enough. The main problem, judging by the threads on builds@, are > > the Windows slaves. I see two major problems here: > > > > 1. The stability of the servers - they seem to go offline quite often, > > requiring manual restarts. Not sure where this problem lies though. > > > > 2. Misuse of the available resources. Just have a look at the load > > statistics for windows1: > > https://builds.apache.org/computer/windows1/load-statistics > > It currently has an avarage queue length of 12! With only 2 machines > > available (currently only 1) we need to limit the amount of work the > > can be put on them. Again I see two parts of the problem: > > > > 2.a Extremely long running builds, i.e. builds that take 10+ hours to > complete. > > Example: > > https://builds.apache.org/job/river-qa-refactor-win6/buildTimeTrend > > > > 2.b Timer started jobs. If these slaves are to be used as *build* > > servers we cannot afford to allow builds to run when there have been > > no change in version control and no changes in upstream jobs. > > Example: > > https://builds.apache.org/job/ZooKeeper-trunk-WinVS2008/ > > > > Note: the examples above were selected randomly from the currently > > running jobs. I'm sure there are lots of other projects doing similar > > things. It is not my intention to single out these projects, but to > > provide examples to back up the points I'm trying to make. > >
