breskeby commented on PR #14781: URL: https://github.com/apache/lucene/pull/14781#issuecomment-2973619493
> Right... This is among those things I mentioned that I don't understand - perhaps there are benefits to configuration caching or other advanced features... but overall it's a lot more boilerplate for something that is conceptually dead simple and that should remain simple. Eh. One problem that gradle is suffering from is, all the freedom it had given in the (groovy) DSL implementation in its early days. which makes it hard to move forward with making substantial progress on optimizing the gradle configuration phase. In this example just everything was kind of slammed into the project object (type Project) which is mutable by contract which makes optimizations way harder. Since ~2 major releases, Gradle keeps slowly deprecating and cutting back on this. Furthermore some of this "magic" like the way Conventions had been implemented back then makes IDE support way harder. Currently almost all of the build logic is jammed into the gradle files. The approach Gradle recommends usually is to keep convention plugins and build scripts small and only contain conventions and a few configurations and keep more complex implementation logic in testable binary plugin and task implementation. "Weired" boilerplate like the "InjectedExec" class I added as part of this PR I consider workarounds to achieve stuff in in build scripts that should probably better live in this binary (plain java?) implementation. There the boilerplate is usually minimal and not as bad as when staying with gradle files only. -- 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...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
