On Jan 15, 2015, at 2:29 PM, Andreas Gudian <andreas.gud...@gmail.com> wrote:
> 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). > I don't think scripting anything you want is a great idea. But there are already examples of writing plugins inline in a form of a POM: https://github.com/takari/maven-polyglot/blob/master/poms/pom.rb What I described in the in the previous post where you can create extensions points for plugins already could be augmented to allow those extension points to be scriptable. That might be convenient but that still doesn't change the default lifecycle and doesn't require a complete regression to full-on scripting whatever you. > 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 > You can certainly have Java-based extension points now, and if you wanted to provide some scripting you can but what would you see that actually looking like? And for what? > 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 >> >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
