I have the following directory structure specified in my IML:
<content url="file://$MODULE_DIR$"> <sourceFolder url="file://$MODULE_DIR$/src" isTestSource="false" /> <sourceFolder url="file://$MODULE_DIR$/test" isTestSource="true" /> </content>
It all works fine, but every time I make a clean (without .idea/workspace.xml) source tree checkout from my svn,
those sourceFolder declarations are getting IGNORED and the new workspace.xml contains only the default specifications (src/main/java, src/test/java etc),
so I have to manually reset them back to make everything (tests, to be specific) working again
Does anyone have any idea on how to fix this issue in my IDEA 13.1 CE?
Thanks in advance!
Workspace.xml contains a lot of settings for different purposes. Could you specify the component containing these paths? As a sample:
<component name="ArtifactsWorkspaceSettings"> <!-- this is a component -->
... <!-- settings in question -->
I'm not a workspace.xml expert. I suppose the information was inside ProjectView:
<component name="ProjectView"> ... <panes> <pane id="ProjectPane"> <subPane> <PATH> ...
Al least this component is totally missing in a newly generated workspace.xml.
Let me put it more clear.
Here's how my module structure looks like now:
And here's how it would look like if I delete workspace.xml and reopen it:
And this is my problem. The "test" and "src" directory specifications are getting reset (causing some other compilation problems) to some wrong values after every svn checkout, even though my syntaxJ.iml keeps the correct sourceFolder specification.
Workspace.xml has no relationship to your problem.
Look at the screenshots. In "after" shot the paths specified at right (like src/main/java) are different to ones specified on "before" shot (like src). It means that although .iml content "before" and _at some moment_ "after" was the same, some IDE subsystem has redefined the paths anyway.
Do you use gradle? It could be some re-import from gradle.
Well, I believe workspace.xml has something to do with my problem, because it was the only file I touched
But I've got your point.
Yes, I use gradle and it seem the IML files are getting regenerated indeed. Sometimes they are left intact though, but I guess this is the way how gradle work...
This is all very weird. But at least I know where to look at now.
Thanks for the tip Alexander!
I'll ask our gradle tester to take a look on this.
Evgeny, .iml files describe module dependencies and content roots. As soon as these items are changed by the means of Gradle, .iml files get regenerates to reflect the changes.