This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
I am looking for some information or documentation on the use of memory by Maven. Does it grow with the size of your ear/war/jars, number of java files compiled, plugins used etc. And how? What is the pattern?
So our maven builds would tell us via the logs :
Total time: XXXMM:SS:MSSS
Finished at: XXXDATE
Final Memory: 24M/58M
So, above, 58M max was to be utilized by default unless MAVEN_OPTS are set to a different value.
But how do we do capacity planning with Maven in terms of the hardware's memory which will be used for the builds to run? How much memory would Maven take given you know the number of ears/java files/plugins used etc ? Is there any empirical way to derive it?
No there isn't, that I know of. One of our builds causes an OOME with the default memory settings (which we run into each time someone sets up a new dev or build machine), so we set the max heap to 1024M. But the thing is, once you know what is needed for a build, there is rarely any need to change it - the memory requirements for a build will not change all that much unless you are adding dozens of classes to your app each day.
We have a huge multi module project, and we are just about finishing up mavenizing the whole build. We have lots and lots integeration tests. QA adds like a 1000 cases every 3 months, and over the past 5 years, we easily have 10K+ integeration tests. We do run OOM even after setting max memory to 1G. What we ended up doing (actually haven't done it yet) is divide up the test cases by test scenarios, and group related test scenarios under a profile. We use team city as our CI server, and team city has these feature where you can have several agents running under team city. We have setup a TC build for every profile, and on a daily basis our agents wake up and start running the TC builds. The advantage here is that integeration tests all run in parallel, and also we limit the amount of memory required by each build. Oh yeah, we have the unittesting on the grid
I don;t know of anyway of sizing your Maven build. That's almost like asking "how do you know how much memory to give to Eclipse?". Most people do it empirically; ie; keep using it till it runs out of memory, then complain till someone gives you more memory
If you have a really large project, Maven does provide strategies that can be used to limit the scope of your build. If you have a large team of like 50 developers and 70 QA who are constantly checking in code, you are obviously not going to have everyone build your entire repo everytime. You will probably have to come up with a way so that developers build their own piece. The CI server will need to be sized empirically, and if you are really big, you will have to start thinking about multiple CI servers