should *.IML be check in the project SCM?

ipr and iml files were supposed to be shared, but frankly, sharing them has caused me more trouble than benefit. It's not like I create a new project every hour, anyway.

Hello nodje,

Yes, the .iml files are supposed to be checked in to the version control
system. Paths to dependencies are either stored as relative paths (if the
dependent files are located under the project) or can be stored using path
variables (if they are not).

If there are specific issues that prevent you from sharing .iml files, you're
welcome to file JIRA issues. (In particular settingsPath looks like something
that needs to be stored in .iws rather than .iml/.ipr).

I've recently started to use Shared scope and for that reason realized
I could check in the IPR file in our SVN.

From some post I can't remember I understood I should check in the IML
as well to be able to share the Facet between developers.

I just realized the IML contains the path to the dependencies and so
cannot be shared. We use a Maven project, so the dependencies are
automatically created.

Isn't the IML supposed to be sharable? If not how do you share Facet
on a project?

Besides, we work on two different plateforms, OSX and windows, and
with the same 7821 build, when we open the project from the identical
pom.xml file, we get the this this main difference in the IPR:

(this part comes from the Windows one, and does not exist on the OSX
side, and there's actually a plateforme dependent path inside!!!)

<component name="Maven Reloaded">
<option name="config">
<value>
<option name="pluginEnabled" value="false" />
<option name="offlineModeEnabled" value="false" />
<option name="updateClasspathsEnabled" value="true" />
<option name="sortDependenciesEnabled" value="false" />
<option name="removeDuplicateDependenciesEnabled"
value="false" />
<option name="respondToPomChangesEnabled" value="true" />
<option name="manageSourceRootsEnabled" value="true" />
<option name="manageModuleInterdependenciesEnabled"
value="true" />
<option name="downloadSourcesEnabled" value="false" />
<option name="downloadJavadocEnabled" value="false" />
<option name="generateSourcesEnabled" value="false" />
<option name="settingsPath" value="C:\Documents and
Settings\Allence05/.m2/settings.xml" />
<option name="searchFilter" value="" />
<option name="disabledPoms">
<value>
<collection type="java.util.TreeSet" />
</value>
</option>
<option name="moduleInterDependencies">
<value>
<map type="java.util.TreeMap" />
</value>
</option>
<option name="logLevel" value="1" />
</value>
</option>
</component>
<component name="MavenBuildProjectComponent">
<option name="mavenExecutable" value="" />
<option name="Settings File" value="" />
<option name="mavenCommandLineParams" value="" />
<option name="vmOptions" value="" />
<option name="useMavenEmbedder" value="false" />
<option name="useFilter" value="false" />
<option name="Batch Mode" value="false" />
<option name="Check Plugin Updates" value="false" />
<option name="Debug" value="false" />
<option name="Errors" value="false" />
<option name="Fail At End" value="false" />
<option name="Fail Fast" value="false" />
<option name="Fail Never" value="false" />
<option name="Lax Checksums" value="false" />
<option name="No Plugin Registry" value="false" />
<option name="No Plugin Updates" value="false" />
<option name="Non Recursive" value="false" />
<option name="Offline" value="false" />
<option name="Reactor" value="false" />
<option name="Strict Checksums" value="false" />
<option name="Update Plugins" value="false" />
<option name="Update Snapshots" value="false" />
<option name="Skip Tests" value="false" />
<pom-list />
</component>
As for the IML, apart from the lib path that are different, we've
found a weird <component name="POM File Configuration" pomFile="" />
in on of the IML. Wondering if that matters?

I atached the 2 different imls for reference.

-nodje

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

I'd be happy to start filling JIRA issues but I'm not too clear on what is right and what's not, yet.

Right now, among others, I can see a lot of problems coming from path, even though they are relative. As far as I understand, IML and IPR are meant to be shared, even between different IDEA instances running on different platforms. If that statement is right, I propose to list the problem I've identified, then you tell me what I should fill in JIRA and what should be fixed on our side.

Here are some of the problems we face.


-

In the section, there's a ]]>

element that should be a relative path.
See full XML above. In any case, the path should be relative, so it's probably a good one for JIRA. But it should be more than that, the path to the .m2 dir should be a variable.
-

This component is part of the IPR. It seems to me it's setting some workspace properties. Shouldn't it be in the IWS?

]]>
-

We have this component changing accross IPR:

]]>

Don't know what it is. How come it changes? If it's user dependant shouldn't it be in the IWS?
-

This path is absolute. Even if relative, it wouldn't work accross machine and platform unless the path to subversion config becomes a variable.

C:\Documents and Settings\xxxx05\Application Data\Subversion the path an OSX: $PROJECT_DIR$/../../.subversion]]>
is relative
-

-

IML contains the libraries for the web module. they are located under ... ... ... ]]>

Those ones should be ordered when created from a om.xml, because it seems they are now created in a random order, which make the IML different in each every instance
-

The libraries for the module contains a path relative to the $MODULE_DIR$ when created from a pom.xml. That doesn't make them compatible on different machine where the directory hierarchy might be different.

Ex: this on a Windows IDEA

... has this equivalent on a OSX ]]>

Once again the path to the .m2 dir should be a variable.
-

Is there actually a documentation available on the IPR and IML structure? There's so much in them, and we have such different results with the automatically generated ones when opening a pom.xml project. It's difficult to manage. A documentation would really help.

I can help concerning the MavenReloaded component : it's the old (before IDEA 7) third party plugin that was providing maven integration,but I think if you're using IDEA 7 you should probably remove it.

thanks Thibaut for the tip.

I'm serious about filling JIRA but I really need to know what should be the way it is and what should be modified.

Another problem we always have in sharing the IPR is the JDK used by the project itself.

Nothing forces users to have the same name for the JDK. This makes the IPR different for each every developer.

Shouldn't this component be part of IWS (while keeping the JDK version in IPR only??)

]]>

-nodje

someone has got to help us here. Otherwise, there will be blood...
It's like the fight for the right config and for who has broken what in the team now.

How about this one? It keeps coming from someone config. (he says he has updated to 7821)

]]>

I'm sorry but, does someone really consider the IPR to be a shared project file here?
It seems so full of user level configuration to me.

Help!

Hello nodje,

someone has got to help us here. Otherwise, there will be blood...
It's like the fight for the right config and for who has broken what
in the team now.

How about this one? It keeps coming from someone config. (he says he
has updated to 7821)

<component name="MavenBuilder">
<option name="jreName" value="java version &quot;1.4.2_07&quot;"
/>
</component>

This one seems to come from a third-party plugin.

<component name="MavenProjectsManager">
<option name="version" value="1" />
<option name="originalFiles">
<list>
<option value="$PROJECT_DIR$/pom.xml" />
</list>
</option>
</component>

So what's wrong with this one?

I'm sorry but, does someone really consider the IPR to be a shared
project file here? It seems so full of user level configuration to me.

Yes, we are sharing the .ipr/.iml files for all of our projects internally.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Then you probably have a strict policy as for where to place your libraries, how to name your JDK, and you probably all work on the same platform...

Thanks anyway Dmitry, I'll give it a try in JIRA.

Hello nodje,

Then you probably have a strict policy as for where to place your
libraries, how to name your JDK, and you probably all work on the same
platform...

Yes (all libraries are stored in the source control under the project root),
yes (we have a standard name for the JDK used in the project), and no (we
work on different platforms). We don't currently see any platform-specific
differences in .ipr/.iml files.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

We've been sharing our IPR/IML files since the beginning of IDEA 6 without any problems.

We have a consistent name for a JDK version (ie. 5 or 6) which we've found is enough from a project standpoint, since then people can install any minor version they want. All libraries are defined at the project level and checked in, so this doesn't cause any issues.

I guess if you don't have that control over your team development environment, then it's going to be fairly hard. Then again, everyone should see the benefit of having a centrally-based project configuration and therefore shouldn't find it too hard to adhere to these fairly minor rules...

I'm having a slightly different problem. Our team IS sharing IML and IPR files successfully, both under SVN control. I use a Mac (OS X 10.5.2), whereas other members of the team are using Windows. We're all using IntelliJ 7.0.3-7757.

The problem I'm having is that all of my IML files repeatedly show up in the Changes view as locally "modified", even though there are NO CHANGES to these files. I do a Diff and it invariably reports, "No Differences", as expected. So I do a Revert to clear each of the files from the Changes view, but they reappear shortly. I can't figure out why this is happening; it's as if IntelliJ is periodically touching all the IML files, and the change in timestamp alone is sufficient to trigger the perception that the files have changed and need to be committed, even though the content is unchanged.

Is anyone else seeing this behavior? If so, any ideas on how to avoid it? If this post is considered off-topic in this thread, please accept my apologies. I've submitted a question to Support but have received neither an acknowledgement nor a response.

Thanks!

Hello John,

You need to set the svn:eol-style property for .iml files to "native" (Subversion
| Set Property... in the context menu).

I'm having a slightly different problem. Our team IS sharing IML and
IPR files successfully, both under SVN control. I use a Mac (OS X
10.5.2), whereas other members of the team are using Windows. We're
all using IntelliJ 7.0.3-7757.

The problem I'm having is that all of my IML files repeatedly show up
in the Changes view as locally "modified", even though there are NO
CHANGES to these files. I do a Diff and it invariably reports, "No
Differences", as expected. So I do a Revert to clear each of the files
from the Changes view, but they reappear shortly. I can't figure out
why this is happening; it's as if IntelliJ is periodically touching
all the IML files, and the change in timestamp alone is sufficient to
trigger the perception that the files have changed and need to be
committed, even though the content is unchanged.

Is anyone else seeing this behavior? If so, any ideas on how to avoid
it? If this post is considered off-topic in this thread, please accept
my apologies. I've submitted a question to Support but have received
neither an acknowledgement nor a response.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Hi, Dmitry,

Thank you very much for your prompt response to my question. I did as you suggested (set svn:eol-style to native for all IML files) and that seems to have solved the problem very nicely. Who knew? ;) I'd had no luck finding anything like this in the documentation or via Google. Of course, had I known what I was looking for ("svn eol-style native") the solution might not have been so elusive!

Thanks!

This probably hold true for the IPR files as well, doesn't it?

Hello nodje,

This probably hold true for the IPR file as well, isn't it?

Yes.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"