[GRADLE-1849] Tooling API: expose information about idea module file (*.iml) location Created: 20/Oct/11  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-4
Fix Version/s: None

Type: New Feature
Reporter: Denis Zhdanov Assignee: Unassigned
Resolution: Won't Fix Votes: 1


 Description   

The subj



 Comments   
Comment by Szczepan Faber [ 16/Jan/12 ]

Denis, is it still needed? Why do you need location of the file?

Comment by Denis Zhdanov [ 16/Jan/12 ]

There is no strict requirement. Just to provide full control to the project structure. You see, I've defined the ticket as 'feature' with 'minor' priority.

Comment by Szczepan Faber [ 26/Jan/12 ]

Ok. We'd like to hold up on that feature because it feels 'wrong'. E.g. the tooling api provides the information model but does not know the metadata filesytem structure. It's up to you, on your end to work with the metadata persistent representation.

Tooling api does provide the 'module name' which basically give you the file name (just add the '.iml' extension). The only thing missing would be the project folder which we could make available on GradleProject (from IdeaModule you can navigate to GradleProject via the getter). Does it make sense?

Comment by Denis Zhdanov [ 26/Jan/12 ]

I'm afraid I don't quite understand the rationale behind. There is a dedicated 'idea' gradle plugin that provides various configuration options for IJ model. My proposal was to add one more option that allows to configure *.iml location and expose it to the end-user (please note that it's possible to define *.iml location at IJ GUI when you create new module there).

It's not clear what do you mean under 'project folder' - '.idea'?

Comment by Szczepan Faber [ 24/Apr/12 ]

Hey,

I think I get it now. It is now possible to configure the output file for the ideaModule via build.gradle dsl:

ideaModule.outputFile = file("somewhere/module.iml")

What you're after is exposing this information in the tooling-api, correct?

Comment by Denis Zhdanov [ 02/May/12 ]

Yes, that's right.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:06:02 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.