We have been discussing this in the context of surefire, which uses these extension mechanisms, so both Tibor, Andreas and I are fully aware of what is possible. And as Jason says, there is a spectrum. I'm not sure how the line would be drawn, since ant is very free-form while gradle is "opinionated free form"; they have an idea of a lifecycle like we do.
I think the root problem I personally want to solve is avoiding monolithic plugins that puts every single maintenance need in our hands and makes our mojos increasingly large and overlapping. In such a context I would like a nice mechanism for user extensibility that can be applied in lots of places; I could easily see large plugins like assembly or surefire providing 20-100 extension points each. Maybe maven core would need support for this, maybe just a toolbox plugins can use - I've been pondering various alternatives. On one extreme it would be possible to just keep the consumer pom and move everything else to a scripted file; it would not be too hard and actually fairly compatible. I'm not necessarily advocating such a solution. But I suppose this is where the initial disagreement starts. If you want to keep your users from writing code that interacts with the build or insist that they don the appropriate robes before doing so (require a separate project and all that), we are simply not in the same school of thought. I agree with Igor and others that build tooling is a different "mode" than end user code, so I also tend to think that just picking up "stuff" that is littered in test scope in various random projects is not a good idea. There are a ton of different approaches that could be used to do something like this: Making a separate project is only one of them. You could put extensions in src/build/<plugin>-[<execution>].[bsh|groovy|fortran||scala] and just have them execute as a post-init script on the plugin. Plugins could even do that themselves without any assistance from core (but it would get better with core support), just a small helper library that invokes the proper language runtime. There might be one or two practical problems with this approach, but nothing unsolvable. I would find it logical that there might be *multiple* strategies for doing this, supporting scripting, in-project module and external-module. m2e is here because of maven, not the other way around. But I do believe in re-using the good stuff we have, which is why in-project module is my personal favourite since it has a very low footprint. I might be several years too late for this whole ordeal. It might even be that I'm just reinventing gradle. Kristian --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
