[GRADLE-1782] Idea plugin: use 'project library' instead of 'single module entry' libraries Created: 05/Sep/11  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

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


 Description   

Consider the situation when we have multi-project where more than one module uses the same library (e.g. 'junit'). The 'idea' plugin generates IntelliJ IDEA project files ('.ipr', '.iml') that use 'single entry module libraries' then. That means that every module has its own setup of the target library. So, every time we want to change it (e.g. reconfigure it to use a new version) we need to change settings of all modules that use target library.

Alternative solution is to configure 'project library' instead and reference it from the modules. That allows to change library settings in one place and have that to be automatically reflected to all of the modules.

P.S. All modules generated by the 'idea' plugin reference the same library from the gradle cache already. So, there is no point in using other approach at the project setup.

 Comments   
Comment by Szczepan Faber [ 24/Apr/12 ]

Hmmm, I need to think a little bit more about this feature.

Since the 'single entry modules' are generated automatically from the builds I don't think there's a problem with duplication of the libraries.

Making module libraries -> project libraries will make them harder to sync, garbage collect, etc.

Comment by Denis Zhdanov [ 02/May/12 ]

I'm afraid I don't get your point. I'm talking about obvious inconveniences for the IJ end-users. Am I right assuming that you are referencing internal tooling api implementation details under 'Making module libraries -> project libraries will make them harder to sync, garbage collect, etc'?

Comment by Szczepan Faber [ 07/May/12 ]

>I'm talking about obvious inconveniences for the IJ end-users.

Can you point me to a relevant user report / feature request? We've never had a request to automatically create project libraries so I don't really see any obvious inconvenience. However, I might be wrong

Here's how you've described the use case:

That means that every module has its own setup of the target library. So, every time we want to change it (e.g. reconfigure it to use a new version) we need to change settings of all modules that use target library.

The workflow of working with the idea plugin is that a dev needs to re-run the idea tasks when the dependencies change. We don't have any step that requires to manually change the settings of all modules. To me, the use case does not really warrant any changes in the current behavior. Also, as you pointed out - it's not quite easy to manage on our end.

Thoughts?

Comment by Denis Zhdanov [ 09/May/12 ]

Hi,

I'm afraid I'm unable to provide you a link to the corresponding report (at least at the IJ tracker) because current IJ gradle integration uses project libraries already. So, now I'm talking mostly about my perception as an IJ user.

The 'change->regenerate' project workflow address the problem but I think it can't be used all the time - as far as I understand it completely regenerates the config files (doesn't try to preserve IDE-local changes made by the user).

I.e. my 'gradle idea' usage scenario would be 'generate initial project setup -> live at the IDE level'. However, it's a subjective point of view.

Comment by Szczepan Faber [ 09/May/12 ]

The 'change->regenerate' project workflow address the problem but I think it can't be used all the time - as far as I understand it completely regenerates the config files (doesn't try to preserve IDE-local changes made by the user).

Actually, it's a bit smarter as it merges the user's modifications. For example, if you manually add a brand new library not mentioned in the build.gradle it should preserve it.

The merging feature has its limitations but in general it worked quite well for majority of cases.

Thanks for the info, Denis. We can leave this ticket open for some time and wait for more feedback from other users.

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:04:12 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.