I think that we don't need to fully open up our plugins so that anyone can customize each aspect "on the fly". We would too much hide the fact that the execution is highly customized because some special stuff is hidden on the classpath somewhere.
Likewise, if we allowed that sort of customization directly as script in the pom, then we'd try to mimic something that other tools like gradle already do - that may be good for some use cases (and then you should use gradle), but it's not what Maven is there for. What especially liked about Maven after years of Ant was, besides the dependency management, the uniformity of all those different maven projects. Maven has still a lot room for improvement, sure. Allowing the complete redefinition of mojos via scripting in the poms is not something that I would see as an improvement (plus, there are all those drawbacks on coding, testing, debugging, as Kristian already pointed out). For the big picture, I think it would suffice if we found and agreed upon a handy mechanism to allow users to hook in at _defined_ places (e.g. for Surefire the processing of the list of tests to execute, reporting, maybe forking, ..). I'd say such a mechanism is "handy", if it fulfills the following requirements: * pulling in a client-api does not mean I also get all sorts of other maven-specific stuff on my classpath * it should be possible to pick up the exension from the current reactor (from the classpath - or perhaps we use some new packaging-type or something) * it should be easy and maybe encouraged to publish extensions - that should be a no-brainer in any case, but perhaps there's something we can do to help people find existing extensions - similar to the way you find plugins for Jenkins Andreas 2015-01-15 11:57 GMT+01:00 Tibor Digana <tibordig...@apache.org>: > Maybe Jason can bring some light into this discussion. > Jason? > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Plugable-Softcoded-Customized-Maven-Plugins-tp5823365p5823611.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 > >
