cstamas commented on PR #4: URL: https://github.com/apache/maven-scripting-plugin/pull/4#issuecomment-1977439877
It is not all black or white of course. We do need some "backdoors" open, for case of "emergency", if no plugin exists that does what you need. But if you google it, you will see the trend: "use hack in maven, but if you need it too often, write a plugin for it" tendency. And we must not lose this. This is why originally writing maven plugins was possible using ant scripts and beanshell as well. Beanshell, Ant script, they were all there to lower the plugin authoring barrier, BUT, those were plugins, they used plugin API, had descriptors, etc, so any future thing like build avoidance, incremental build (real one, not what we have today), etc. could rely on them. Problem is when "hacks" remain hacks, or worse, when "hacks become pattern" (of using some "special" (backdoor) plugin). So if you have ant/exec plugin in build, it is okay, as long as you do not stick with it. But in our case, I see pattern of building some "library of hacks" on top of these, that makes ANY of these "solutions" non reusable, non shared, not maven plugins If you need something special, hack it once. But second time write a plugin for it. Period. In short, we do need "stepping stone" plugins (hacks, like exec, ant plugins) to solve some ad-hoc scenarios, BUT these are stepping stones, in a sense, if pattern is repeated, they should be made into reusable plugins ultimately, while I see no intention of that happening here. In contrary, I see quite the opposite intent. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
