There's a lot of issues in our issue tracker, not all of them should be solved by such an extension mechanism. So while for instance interpolation to NULL is a commonly requested feature, it'd probably be smarter to just "fix" the problem in interpolation than to make a whole new feature just so someone can sett a value==null. I'm not looking for a silver bullet to rule them all.
I believe this is one of the things gradle got right: A strong project structure and a clear default lifecycle where it's easy to modify behaviour. By making plugins effectively closed for extension I think we are too rigid. While forking a plugin certainly has gotten easier, it's not really what we want either. Kristian 2015-01-14 23:33 GMT+01:00 Tibor Digana <tibordig...@apache.org>: > , but DSL languages is just only a fancy feature which does not solve our > major problem. > > Basically the users claim that our MOJO plugin parameters should have: > + different system properties > + different default values > + different data format > + different handling of MOJO parameters > + system properties are empty strings and some users like it and some other > want to interpret them as NULL > etc. > > This means that Maven core is setting these parameters and the user should > override them. > > Some users want to modify our code much deeply, even in different class > loader or in forked jvm > + RunOrder, > + classes Streamer, > + tests-list processor > + TestNG Listener and workaround TestNG 6.0 bugs (reopened bug in GitHub I > could not accept because it's not our bug, and therefore changing surefire > listener may break other users which is maybe okay for the guy who reported > the issue in GitHub. And he is playing the game with me and pushing me with > reopened bugs, funny :) ) > > > I am not sure, but to me it looks like the Classworld CL should be parent > for another CL creating an instance of plugin MOJO SurefirePlugin.class > extended by users class because he should be able to control the injected > @Parameter(). > I have no idea how to do that and maybe Maven has already some hooks for > that. > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823565.html > Sent from the Maven Developers mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org