Nice. I'm sure we can make it faster, too. On 04/09/2013, at 4:17 AM, Alex Ruiz <alr...@google.com> wrote:
> Hi Adam, > > Good news about performance. I imported a really huge project we have here > and this is what I got: > > Before: 2 minutes 25.4 seconds > After (with new API): 14.5 seconds > > Unbelievable! Thanks, Adam! This is great. > > I'll post more results as I test other projects. > > -Alex > > > On Sun, Sep 1, 2013 at 3:06 PM, kelemen <attila.keleme...@gmail.com> wrote: > 2013/9/1 Adam Murdoch [via Gradle] <[hidden email]> > > On 31/08/2013, at 12:41 PM, kelemen <[hidden email]> 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]> 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]> 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 >> >> >> >> >> >> >> 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 >> >> >> 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 > > > > > > 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. > 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
