The reasons are listed as benefits. I would like to highlight that model queries cannot have an argument. Not having an argument has obvious limitations. Another very important reason: Currently, if I want to add a new model, it incurs a lot of overhead because I have to convience others (for example, you) that the new model is something worth to add. This - of course - helps with the quality of the model but slows down development. If I was able to add models dynamically, then there is no reason to worry too much about quality because even if I create a not so good model, I can just create a new, discard the old one and forget about it. This is currently not the case, if I screw up a model then we have to live with the mistake forever (even though review, assuming that the model is perfect is just unreasonable). In this case, you can even consider the IDE as an incubator of new models where the model can show its worth.
Also, I find the comparison with private fields a little unfair. There isn't anything unspecified, undocument thing I want to access. That is, I just want to rely on API, you already have to keep compatible due to the build scripts out there. There is no strong coupling here. I admit that this changes the original meaning of the model but this shouldn't necessarily be bad. As for comparison: Gradle currently allows to download a plugin from an external Maven repository (like the Android plugin) which then can add a model builder. It does not allow to download this from the IDE. This feels as saying that the IDE is less trustworthy than an arbitrary Maven repository. If this feature does not get added, I will need an awkward workaround where I will have to solve problems you already solve (discovering jars, although it is easier for me to do). This is the workaround, I'm planning: 1. Serialize the instance of `ToolingModelBuilder` and save it to a temporary location. 2. Create a gradle script which adds a `ToolingModelBuilderRegistry` which will rely on the saved `ToolingModelBuilder`. 3. Adjust the build script to put some jars on its classpath. 4. Specify the script as an init script before querying the models through the new API. 5. Query the model provided by the serialized `ToolingModelBuilder`. 6. Delete the serialized instance of `ToolingModelBuilder`. As you can see, it is technically possible to solve the same thing through legal calls. This means, that what you consider "coupling" is already there, only it is awkward to do. If the new API will not directly allow me to do this now, then I will have to support the above way forever (to avoid regression for 1.8). That is, I will have to resort doing this because I (currently) don't agree with the academical reason, therefore I need at least a single example of what problem this can cause in the future (still, it can be measured agains the benefits). The gain in the IDE support just feels too much to be ignored for reasons I don't understand. 2013/8/23 Adam Murdoch [via Gradle] < [email protected]> > 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 <[hidden > email]<http://user/SendEmail.jtp?type=node&node=5711750&i=0>> > 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 > > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711750.html > To unsubscribe from Proposal for retrieving multiple types of models from > a project in a single pass, using the Tooling API, click > here<http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5711516&code=YXR0aWxhLmtlbGVtZW44NUBnbWFpbC5jb218NTcxMTUxNnwtMTMxMjM2NTcwMA==> > . > NAML<http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- 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-tp5711516p5711753.html Sent from the gradle-dev mailing list archive at Nabble.com.
