Hi Devs Actual question is at the end. Some introduction first.
I'm developing two Maven plugins, where actual functionality is not implemented in the plugin, but delegated to "providers". This idea is taken from maven-compiler-plugin, where the plugin delegates compilation to plexus compilers. I've improved this in my plugins by adding provider auto-discovery mechanism based on some project properties, etc. In maven-compiler-plugin default "javac" compiler is added as a dependency by default. You can add other compilers as dependencies and set desired "compilerId". This implementation works because plexus-javac-compiler has no dependencies, so adding other compilers will not cause any dependency conflict. In both my plugins I have (for now) two providers, with conflicting transitive dependencies (different version of the same dependency), so I cannot add one of them by default, because when I would want to use the other one I couldn't remove the first, default one from dependencies, and the resulting classpath after dependency resolution would be unpredictable. The solution is the ability to find and resolve the right provider without the need to add it do plugin's dependencies. This is similar to Surefire internal (so called "well known") providers (junit3, junit4, testng). They are never declared as Surefire dependencies, but Surefire can resolve then in runtime. To improve provider auto-discovery performance Surefire caches already resolved provider dependencies. See: https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/ClasspathCache.java I went one step further and I cache ClassLoaders because repetitive class loading process is very timeconsuming even when cache'ing classpaths. My question is, when can I dispose my cached classloaders? Is there any project build event I can add listener to? I would like to dispose the classloaders at the end of reactor build, not at the end of each reactor module build. Thanks in advance. Regards Grzegorz Slowikowski --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
