Hi Alex, Adam, Alex: I can't test with NBAndroid because the Gradle Android plugin complains about the Gradle version. Is there anything I can do to disable this version checking?
Adam: I can query `EclipseProject`, `GradleProject` and `IdeaProject` but not `IdeaModule`. Another problem is that if daemon is alive and I change the jars (rebuild) then weird exceptions are thrown telling me that a valid jar url cannot be opened. Also, can I ask you to adjust the current implementation of `GradleBuild` to have `getProjects` and `getRootProject` a more meaningful return value. For example: A type through which it is possible to query some of the basic properties of the project (project dir, path, build script). While at it, the API would be slightly more self explaining if you could call `getRootProject().findModel` (and the same for other projects) instead of having the two arguments `findModel` methods. Other problem: gradle-1.8-XXX-all.zip contains the same files multiple times. 2013/8/30 alex.ruiz.05 [via Gradle] < [email protected]> > Awesome!! Thanks a lot, Adam!! > > > On Thu, Aug 29, 2013 at 9:03 PM, Adam Murdoch <[hidden > email]<http://user/SendEmail.jtp?type=node&node=5711779&i=0> > > wrote: > >> Hi, >> >> This is in the release branch now. You can use >> `BuildController.findModel()` instead of `getModel()`, and it will return >> null if the requested model is not available. >> >> >> On 26/08/2013, at 5:22 AM, kelemen <[hidden >> email]<http://user/SendEmail.jtp?type=node&node=5711779&i=1>> >> 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]<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<http://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. >> >> >> >> -- >> 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-tp5711516p5711779.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-tp5711516p5711781.html Sent from the gradle-dev mailing list archive at Nabble.com.
