The mentioned configuration on demand problem seems affect everything even Android projects. Even worse: The following exception is thrown for me: "org.gradle.tooling.provider.model.UnknownModelException: No builders are available to build a model of type 'org.gradle.tooling.model.GradleBuild'." This means that calling `getBuildModel` is impossible.
2013/9/1 Kelemen Attila <attila.keleme...@gmail.com> > I couldn't determine why Alex can load IdeaModule and why I can't. > However, I won't need it because I have successfully implemented arbitrary, > dynamically added model loading (I can workaround the problem even if not > using this). > > Also, there is a *lot* bigger issue: When using configuration on demand, > `ToolingModelBuilder.buildAll` is called with an unevaluated project > instance. This is a blocking issue for me. > > > 2013/8/31 Kelemen Attila <attila.keleme...@gmail.com> > >> Thank you, I have tested loading AndroidProject and it is loaded fine. >> That is, it was loaded with a different ClassLoader than the BuildAction >> and was transferred to me successfully. >> >> However findModel still returns null for me when calling it with >> IdeaModule.class, however IdeaProject.class works despite that Adam said it >> shouldn't. I will investigate it further. >> >> >> 2013/8/31 alex.ruiz.05 [via Gradle] < >> ml-node+s1045684n5711783...@n5.nabble.com> >> >> Attila, I just sent you the files via a separate e-mail. >>> >>> >>> On Fri, Aug 30, 2013 at 10:10 PM, Alex Ruiz <[hidden >>> email]<http://user/SendEmail.jtp?type=node&node=5711783&i=0> >>> > wrote: >>> >>>> Attila, I am able to use IdeaModule as parameter. Here is the code for >>>> my BuildAction. It works perfectly within Studio (I haven't measured >>>> performance yet though.) Also note that I don't make another call to Gradle >>>> to find an AndroidProject, I just check for task names, it is cheap. >>>> >>>> Yes, the Android Gradle plug-in will complain that it does not support >>>> Gradle 1.8. I grabbed the source, removed that check and publish it in my >>>> local repo. I'll send you the zip with the files directly to you using my >>>> personal GMail account. >>>> >>>> public class ProjectImportAction implements >>>> BuildAction<ProjectImportAction.AllModels>, Serializable { >>>> @NonNls private static final String ANDROID_TASK_NAME_PREFIX = >>>> "android"; >>>> >>>> @Nullable >>>> @Override >>>> public AllModels execute(BuildController controller) { >>>> IdeaProject ideaProject = controller.getModel(IdeaProject.class); >>>> if (ideaProject == null || ideaProject.getModules().isEmpty()) { >>>> return null; >>>> } >>>> >>>> AllModels allModels = new AllModels(ideaProject); >>>> >>>> for (IdeaModule module : ideaProject.getModules()) { >>>> if (isAndroidProject(module)) { >>>> AndroidProject androidProject = controller.getModel(module, >>>> AndroidProject.class); >>>> allModels.addAndroidProject(module, androidProject); >>>> } >>>> } >>>> >>>> return allModels.hasAndroidProjects() ? allModels : null; >>>> } >>>> >>>> public static boolean isAndroidProject(@NotNull IdeaModule module) { >>>> // A Gradle project is an Android project is if has at least one >>>> task with name starting with 'android'. >>>> for (GradleTask task : module.getGradleProject().getTasks()) { >>>> String taskName = task.getName(); >>>> if (taskName != null && >>>> taskName.startsWith(ANDROID_TASK_NAME_PREFIX)) { >>>> return true; >>>> } >>>> } >>>> return false; >>>> } >>>> >>>> public static class AllModels implements Serializable { >>>> @NotNull private final Map<String, AndroidProject> >>>> androidProjectsByPath = Maps.newHashMap(); >>>> @NotNull private final IdeaProject myIdeaProject; >>>> >>>> public AllModels(@NotNull IdeaProject project) { >>>> myIdeaProject = project; >>>> } >>>> >>>> @NotNull >>>> public IdeaProject getIdeaProject() { >>>> return myIdeaProject; >>>> } >>>> >>>> public void addAndroidProject(@NotNull IdeaModule module, @NotNull >>>> AndroidProject project) { >>>> androidProjectsByPath.put(extractMapKey(module), project); >>>> } >>>> >>>> @Nullable >>>> public AndroidProject getAndroidProject(@NotNull IdeaModule module) >>>> { >>>> return androidProjectsByPath.get(extractMapKey(module)); >>>> } >>>> >>>> @NotNull >>>> private static String extractMapKey(@NotNull IdeaModule module) { >>>> return module.getGradleProject().getPath(); >>>> } >>>> >>>> public boolean hasAndroidProjects() { >>>> return !androidProjectsByPath.isEmpty(); >>>> } >>>> } >>>> } >>>> >>>> >>>> On Fri, Aug 30, 2013 at 7:41 PM, kelemen <[hidden >>>> email]<http://user/SendEmail.jtp?type=node&node=5711783&i=1> >>>> > 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). 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]<http://user/SendEmail.jtp?type=node&node=5711781&i=0> >>>>> > >>>>> >>>>>> 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. >>>>>> 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. >>>>> >>>> >>>> >>> >>> >>> ------------------------------ >>> 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-tp5711516p5711783.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-tp5711516p5711786.html Sent from the gradle-dev mailing list archive at Nabble.com.
