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-tp5711516p5711785.html Sent from the gradle-dev mailing list archive at Nabble.com.
