2013/9/1 Adam Murdoch [via Gradle] <ml-node+s1045684n571179...@n5.nabble.com >
> > On 31/08/2013, at 12:41 PM, kelemen <[hidden > email]<http://user/SendEmail.jtp?type=node&node=5711791&i=0>> > wrote: > > 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. > > > Right. This is one of the shortcuts that still need to be fixed. The > daemon caches the action ClassLoader, but does not check for changes in the > implementation class path. > > > > 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). > > > That's the plan. We're just implementing this in very small steps. > > > 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. > > > It's an interesting idea. One issue is that the same types are also used > to represent models outside of build actions - that is, are returned by > `ProjectConnection.getModel()`. The semantics of these calls would be quite > different in that context: it would mean starting a new build invocation, > and would not be an atomic snapshot of the model. In this case, it might > actually be clearer to make it explicit that a new model request operation > is required. > > Perhaps we add these methods, but they are only allowed to be called from > within a build action. > > If `GradleBuild` is a requestable model then it would be better (rather than complicate the semantics of `GradleBuild`) to add `BuildController` methods `getRootProjectRef()` and `getProjectRefs()`. Then you could call `controller.getRootProjectRef().findModel`. Of course the return value of `getRootProjectRef` (and the elements of `getProjectRefs()`) would not be `HierarchicalElement` but a new interface. I prefer not making the meaning of these already existing interface context dependent. Of course, in this case the two arguments `findModel` and `getModel` methods of `BuildController` can be removed. > > > Other problem: gradle-1.8-XXX-all.zip contains the same files multiple > times. > > > 2013/8/30 alex.ruiz.05 [via Gradle] <<a > href="x-msg://117/user/SendEmail.jtp?type=node&node=5711781&i=0" > target="_top" rel="nofollow" link="external">[hidden email]> > >> 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 <http://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, <a >> href="x-msg://117/" target="_blank" rel="nofollow" link="external">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-tp5711516p5711781.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-tp5711516p5711791.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-tp5711516p5711793.html Sent from the gradle-dev mailing list archive at Nabble.com.
