Hi, Thanks for the offer, but I'm pretty reluctant to make this change. I really don't want to couple the tools and the build model together. To me, this is similar to, for example, using reflection to mess with the private fields of an object rather than using its interface. Usually a bad idea, particularly when either party can change at arbitrary points in time.
So, let's step back. What's the actual problem you're trying to solve here? That is, what would you use such a builder for? Let's see if there's another way to solve this. On 22/08/2013, at 6:39 AM, kelemen <attila.keleme...@gmail.com> wrote: > Hi Adam, > > It would be a very benefical to allow providing a (serializable) > implementation of `ToolingModelBuilder` through `BuildActionExecuter` for > future evolution of the Tooling API. Adding it now would be a lot more > convenient than adding it after 1.8 was released (less backward > compatibility issue). If you allow me to do so, I will implement it myself > and send a pull request (or a patch). > > Benefits of dynamically added `ToolingModelBuilder` > --------------------------------------------------- > > - Allows to develop models and release new models independently of Gradle > release schedule. This simply allows creating a jar containing > ToolingModelBuilder implementations on which all IDE can rely on, so anyone > can use them. > - It is possible to more easily effectively deprecate models by releasing > another jar. Although such deprected models still need to be supported but > new clients of the Tooling API does not have to know about the deprecated > models (less conceptual overhead). > - You can specify arguments when requesting models. Currently with > ToolingModelBuilder you can only have a fixed set of models. For example, > one might want to allow the users to resolve (and get the resolved > artifacts) a particular configuration by name. Or someone might not want to > resolve the sources or javadoc (note that each boolean argument would > increase the required number of models exponentially). > - It is easier to prototype new models this way when developing IDE > integration. > - Unused ToolingModelBuilder instances do not cause needless overhead. > - The ToolingModelBuilder interface allows for implementations scaling > quadratically with the number of model builders. Adding ToolingModelBuilder > dynamically, it would be relatively simple to design an API on the top of it > which scales well. This new API can be released in later versions of Gradle. > > > Disadvantages > ------------- > > - Additional work to implement. > - Might need some additional maintainence cost. > > > I hope you also find this new addition to be useful. > > bye, > Attila Kelemen > > > > -- > View this message in context: > http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711744.html > Sent from the gradle-dev mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us at the Gradle eXchange 2013, Oct 28th in London, UK: http://skillsmatter.com/event/java-jee/gradle-exchange-2013
