Hello Jörg, this seems to be a really big project. We have a similar situation (department-pom, which manages a lot of external dependencies and internal dependencies as well as plugin versions and even executions). And of course the internal dependencies use different versions of this department pom (some even 5 years old :-)).
I inspected a moderately sized project (60000 LOC, 16 modules). `mvn validate` did download 23 versions of the department pom. Duration was always about 12 seconds when done repeatedly. All runs with idk 1.7.0_80 MAVEN_OPTS="-Xms64m -Xmx512m -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=192m -Djava.awt.headless=true" mvn305: Final Memory: 44M/750M mvn325: Final Memory: 49M/526M mvn331: Final Memory: 48M/526M mvn335: Final Memory: 48M/526M However our inheritance depth is normally only department-pom -> aggregator/parent-pom. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Fri, Jul 24, 2015 at 10:02 AM, Jörg Schaible <[email protected]> wrote: > Hi Igor, > > Igor Fedorenko wrote: > >> I am pretty sure somebody provided an example project that showed memory >> increase in Maven 3.2.x some time last year iirc. > > That was me. I've provided everything to run "mvn validate" on the project > tree. I have that archive still around. > >> Could have been direct >> email, not 100% sure. > > At least over a private channel, since the project is not public. > >> From what I remember, the problem was triggered by >> specific way to reference parent pom, this is why only few projects are >> affected. Our performance regression test suite caught the problem too, >> but we never had time/resources to fix it. >> >> Again, going by memory, there are several problems, each of which >> increases memory footprint, so the solution likely requires multiple >> changes in different parts of the core. Deduplication of inherited model >> elements, things like <dependency>, is the likely best long term >> solution, but it is also the most involved and will likely require >> changes to modello and the way models and constructed and used. >> >> http://www.mail-archive.com/dev%40maven.apache.org/msg102715.html > > Ah, yes, you've created MNG-5669 ... > > Cheers, > Jörg > > > > --------------------------------------------------------------------- > 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]
