On 31/08/2013, at 12:41 PM, kelemen <attila.keleme...@gmail.com> 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. > > Other problem: gradle-1.8-XXX-all.zip contains the same files multiple times. > > > 2013/8/30 alex.ruiz.05 [via Gradle] <[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, 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
