On 01/09/2013, at 11:23 AM, kelemen <[email protected]> wrote:
> 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.
This should be fixed now, in the 'release' branch. Can you give it a try?
>
>
> 2013/8/31 Kelemen Attila <[hidden email]>
> 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] <[hidden email]>
>
> 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]> 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]> 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]>
> 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.
>
>
>
>
> 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.
> 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
