Surefire is in a special case, because surefire makes its own classloader, in fact several of them. So theoretically you could dump a blob of smalltalk into the config section of pom.xml and fire up embedded smalltalk inside the plugin (or maybe cobol =:-). For the single case that is surefire, anything can be done. All of this could be implemented in surefire in an afternoon of hacking. I'm not particulary fond of this solution, for several reasons. Firstly it is surefire-only. And we're not leveraging maven's existing strengths very well and we'd be loosing a ton of tool support. I have built a strong dislike for creating lots of "micro-contexts" that can be used to run particular DSL-code, like the verify-code in maven-in-invoker. What's on that classpath, really ?
With a distinct module you leverage all the things we have that are good. The classpath of that module is effectively imported into the plugin, you can yourself control any dependencies. You also control the language in use. If you choose a language with decent tool support you may get intellisense and full IDE support for the available features in the module you have defined; the extension points just roll down with autocomplete and javadocs all at hand. You could also get access to the plugin's configuration section. Possibly you could even just add custom settings for your extension. I don't have all the answers here; I've been thinking about this stuff for several years and it's not entirely clear how this can be improved and still remain the same product; dumping a ton of code into pom.xml will only make us a bad gradle-imitation :) You could dump a "<plugin>-<execution>.[groovy|scala|clojure] right beside pom.xml and just strap up groovy/scala/clojure for that execution and run it. If you accept that such a script runs in the plugins class realm you could be pretty much done. And that clojure script could contain plexus annotations and those components *could* be made available for late-bound lookup. Hmpf. Kristian 2015-01-14 19:04 GMT+01:00 Tibor Digana <[email protected]>: > Kristian, i cannot imaging how will be customizing a dependency extension. > For instance each module should change the runOrder differently. Should I > then build tons of module extension for each project separately? > The extension code should be in src/test/java or another module, but both > cases should be supported. > As i understood the plugin's classpath does not have test classes, then > there must be an additional ClassLoader to proxy the plugin's ClassLoader > and to load the MOJO AbstractSurefireMojo.class and make injection of > @parameters on new proxy instance again, or? Is it possible to extend the > Classworld ClassLoader in plugin runtime? > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823548.html > Sent from the Maven Developers mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > 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]
