Sure. I'll try to add this before the release. On 26/08/2013, at 5:22 AM, kelemen <attila.keleme...@gmail.com> wrote:
> 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 <[hidden email]> > 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] <[hidden email]> > > 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]> 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. > NAML > > > > View this message in context: Re: Proposal for retrieving multiple types of > models from a project in a single pass, using the Tooling API > Sent from the gradle-dev mailing list archive at Nabble.com. -- 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
