A small request for change before release: This is nothing big but can you add `org.gradle.tooling.BuildController.tryGetModel` instead of `org.gradle.tooling.BuildController.getModel` where `tryGetModel` returns null when the model is not found? This is because a model not being available can be totally expected. For example, I can only determine that a project is an Android project by querying `AndroidProject`.
2013/8/23 Kelemen Attila <attila.keleme...@gmail.com> > 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] < > ml-node+s1045684n5711750...@n5.nabble.com> > > 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-tp5711516p5711754.html Sent from the gradle-dev mailing list archive at Nabble.com.
