Is this planned anytime soon?
Each time new maven modules is added, I simply create a new idea project from the poms.
Sadly, this leaves me with non-flex modules on all my flex modules.
Quite irritating, to say it the least.

Hi, Per,
I don't quite understand what you meant to say.
Why do you create a new project every time?

We have a project that build with maven. To avoid having to maintain two kind of project files, we only maintain pom.xml files as part of what comes in the source repo. When new modules are added to the project, or when new project members come on the team, they simply create idea project from poms. But the modules, that have <packaging>swf</packaging> (or "swc") in their poms, are not recoqnized as flex modules by idea. Hence the need to delete them and readd those modules manually after each "create idea project from poms" operation.

Why don't you want to keep ipr/iml files in the vcs?

We have previously had problems with this approach, as the environment of the developers are different. I know we can do stuff with path variables and the like, but it always seem to fall through on some point somewhere. Or at least, it did at that time. And then, when some developers on the team upgraded from v6 to v7, while others didn't, the project files needed upgrade for some and not for others. Yada yada yada, long story short, we had trouble with that.

Nevertheless, I find this issue to be separate from the solution of keeping project files in vcs. IDEA still doesn't recoqnize the module types correctly. Shouldn't it do that?

Yes, we do not currently support flex modules.
The problem is that it is practically impossible to support all possible module types.
So far, we have implemented support for most common ones (jee); and are likely to support more; but I can't tell you how soon it will be. Probably after 8.0 milestone.

I agree that it must be "..practically impossible to support all possible module types..". But, given that you, in IDEA itself, have a type "flex" module already, shouldn't IDEA be able to recoqnize that from the poms? I keep telling my colleagues that they should stick with IDEA and drop the eclipse/flexbuilder thoughts, as, ... as I say, "Jetbrains is doing flex support in the upcoming 8.0 version".

I know some parts of idea is open sourced. Should I, or one of my colleagues, get the neccessary resources, would this be something we could contribute? Is the maven integration open sourced?

Yes, the Maven integration is open-source:
http://svn.jetbrains.org/idea/Trunk/bundled/maven/
Patches to add this functionality will be very much welcome.

Initial flex support implemented.
Will be improved with Flex support evolution.

This one has been closed as resolved, even though it is not.
About the comment "Will be improved with Flex support evolution" - what will make sure, that this will improve like written. Should I open other issues on the missing parts of import?

Like:

• it puts a flex facet on the module, even though it should be a flex module, not facet
  
• it doesn't add flex libs from pom dependencies
  
• it doesn't resolve dependencies between poms and setup idea module dependencies properly
  

Per,

When I closed the issue IDEA had only basic flex support.
Therefore the only setting that could be imported was flex.home property.

Now It has a bit more settings, but it support flex2 mostly, not flex2. I'm planning to improve flex-maven integration as flex developments goes.

As for your questions, why should it be a flex module, not a module with flex facet?
As for dependencies, could you attach the maven project I can use as a sample?

Thanks.

I had the understanding that the flex facet was the "old way" (in v7) og having flex support, while v8 will provide flex module support instead. If this is not so and a flex facet is just as powerful, then I guess it can be okay as it imports today.

Regarding dependencies, I will attach a project shortly.

After import of this, the idea project flex setup should include:

• "common" module should be type lib, not application (due to packaging element)
  
• "app1" module should depend upon "common" module
  
• Both "common" and "app1" modules should have dependency on puremvc library