I prefer more reliable ways as this does not imply that non-android projects do not contain such tasks. That is, I would rather catch the `UnknownModelException` than check for such a task. This is a minor issue though.
2013/8/26 alex.ruiz.05 [via Gradle] < ml-node+s1045684n5711755...@n5.nabble.com> > You can figure out it is an AndroidProject or not by querying the tasks. > Android projects have at least one task that starts with "android". > > > On Sun, Aug 25, 2013 at 12:22 PM, kelemen <[hidden > email]<http://user/SendEmail.jtp?type=node&node=5711755&i=0> > > 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]<http://user/SendEmail.jtp?type=node&node=5711754&i=0> >> > >> >>> 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]<http://user/SendEmail.jtp?type=node&node=5711754&i=1> >>> > >>> >>> 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. >>>> 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: Re: Proposal for retrieving multiple types >> of models from a project in a single pass, using the Tooling >> API<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<http://gradle.1045684.n5.nabble.com/gradle-dev-f1436218.html>at >> Nabble.com. >> > > > > ------------------------------ > 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-tp5711516p5711755.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-tp5711516p5711756.html Sent from the gradle-dev mailing list archive at Nabble.com.
