OOM for large multi-module maven project

[sta4152]

Having a large multi-module project of ~170 modules (tree, up to 4 levels, not just a flat list of sub-modules).
There are several "heavy-weight" dependencies involved, e.g. camel, karaf, spring, activemq, jetty
It builds fine (mvn clean install) with 2G max heap for maven build (MAVEN_OPTS).
It fails with OOM on running "mvn package license:add-third-party". Even with increasing max heap to 12G. Same for aggregated-add-third-party. But works for download goals (at least with 4g heap, not sure if even with the original 2G).

In the heap dump generated on failure (with 8G max heap to be able to handle it) I can see with the MAT that this seems caused by references to the DefaultThirdPartyHelper, the MAT identifies as one possible cause:
1.177 instances of "org.codehaus.plexus.classworlds.realm.ClassRealm", loaded by "sun.misc.Launcher$AppClassLoader @ 0x5c1578b90" occupy 4.153.777.392 (62,53 %) bytes.

On having a closer look to the 14 largest ClassRealm instances wrt retained sizes (100 - 200M), the memory is consumed by org.codehaus.mojo.license.api.DefaultThirdPartyHelper instances' artifactCache field, referenced via

ClassRealm: classes (java.utl.Vector)
  -> Vector: elementData (Object[])
    -> Vector: elementData[xxx] (DefaultThirdPartyHelper)
      -> DefaultThirdPartyHelper: artfactCache (TreeMap)

I am no OOM analysis export. Nor am I a maven plugin developer knowing the maven internal mechanisms. But as this happens only (AFAIS) on using the license-maven-plugin and I see it's classes involved in consuming the heap, I think it's here the correct place to raise an issue at ... ?

[cwholmes]

Seems to be the same issue as #375