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. > > 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). This change is in the release branch now, if you want to try it out. The type is called `BasicGradleProject` for want of a better name (suggestions for a better name welcome). > 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] <[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
