We have a medium-large project (~30 modules) with about a dozen active developers. The modules are a mix of about 2/3 mavenized and 1/3 non-mavenized (see IDEA-16834). Our code style, compiler settings, inspections, module groups (see IDEA-16833 and IDEA-16835), and facet inclusions/exclusions are all project-specific and saved in a version-controlled ipr so that all developers shared those settings. The non-mavenized projects have version-controlled iml files and the mavenized project's iml files are generated. We currently use the maven-idea-plugin to generate all of the iml files for mavenized projects (e.g. mvn idea:module) outside of IDEA, but would like to start using the native maven support instead. All of my efforts thusfar have failed though. I may be missing something, or perhaps there really isn't a way to combine the features we'd like to combine.
I tried creating a project ipr which contained my projects settings, includes custom modules groups, and references to all of the modules (manual and maven-generated). When the project is checked out and opened in IDEA, the mavenized modules don't have .iml files and IDEA displays a number of "cannot load module" (see cannot-load-module.jpg) dialogs, to which I select "No" (do not remove module). After pressing no for each missing iml file, the maven import fails with a "The project was imported with a previous Maven Plugin version. Please reimport to make it work properly." message (see previous-maven-plugin.jpg). Pressing the synchronize with maven projects button at this point simply fails with no warning or error messages.
The scenario I described above doesn't seem that far-fetched to me. In fact, it seems like it would be quite common. In any case, without a solution or a workaround, we're completely unable to leverage the native maven support. I'd be happy to describe any aspect of this in greater detail.
It might be as easy as including a flag in the ipr on a <module ... /> element (where module group is defined) that indicates that the module iml should be generated via maven. This step would occur early in startup, and if the iml was missing for a mavenized module it would be then be generated. This would allow us to associate project settings with a version controlled ipr but leave the mavenized module generation to the native maven plugin.
Environment: Windows Xp
Issue was closed
The supposed scenario (and the only supported one so far) is using 'Import' feature or opening pom.xml. This way all the modules will be automatically configured and corresponding iml files created.
- Import a multi-module project from maven (file menu > open project > pom.xml).
** This creates an initial acme.ipr, acme.iws, and one .iml for each mavenized module.On a different machine:
- Checkout the above project
- Open the commited .ipr (containing project specific settings)
** For each module, the error captured in cannot-load-module.jpg is displayed** After the cannot load module dialogs, the error captured in previous-maven-plugin.jpg is reported
This makes it impossible to commit into version control project specific settings in an .ipr when using IDEA to generate .iml files. The .iml files cannot be added to subversion because they include many absolute paths and thus are specific to individual developer's machines.
On a large project there are significant benefits to sharing code styles, error settings, compiler settings, and facet exclusions across a team. Note that there are other settings saved in the .ipr that are also useful to share, like module groups and references to non-mavenized modules (I've created separate issues for these: IDEA-16833, IDEA-16834, and IDEA-16835).
The absolute paths, as far as I know, are only paths to maven repository artifacts.
To warkaround you problem you can use path variables. Create one that points to the maven repository on specific machine - iml files will contain paths that are relative to this path variable and you will be able to share them.
Have you considered automatically adding and using an "M2_REPO" path variable as part of maven support?
Though any arguments are welcome 8)