If you've got sufficient complexity in your build environment to get into situations like that, the last thing I'd be considering would be to move from a disciplined build environment like Maven to an ad-hoc one. Especially just to make an IDE happy. One of the reasons I'm so big on UI-free build processes like Ant and Maven is that GUI-based builders come and go, but the text-based stuff is more stable. And stability is critical in a large business environment.
I'd consider turning off the Eclipse auto-build instead. Which I've done on occasion when Eclipse got its wires excessively crossed.
However, since recent versions of Eclipse have been better behaved in that area (just don't ask me my opinions about its XML/HTML editors ), if I were you, I'd map out the Maven inter-dependencies and ensure that they weren't truly circular. Because if they are, you can't reliably build everything from scratch on a cold machine. And that's the kind of stuff that makes me nervous.
Customer surveys are for companies who didn't pay proper attention to begin with.
oh no they aren't really circular, somedays it just works. There are people here much cleverer than me trying to get the eclipse m2e pulgins working properly, but somedays they just don't.
My intention was just to get a clean eclipse without maven, and use the command line for all the maven stuff, then refresh eclipse when i need to. I know it isn't ideal but i think i got about 15 -2 days actual work done last week (i work full time).
and because of the build problems we are trying to only have the fewest projects open at once, and all the thrashing is adding to the problems, making jboss unhappy (projects go missing from the deployment assembly).
I doubt the problem is with eclipse2me, which is mostly driving background batch. The problem is typically when Eclipse tries to sync up with the out-of-band changes. That's assuming that you don't have Eclipse set up to run Maven automatically on changes. I don't. Because even without circularity the overhead would be unspeakable.
As a completely tangential observation, one thing I've noticed is that the places in a project that "should" be consuming the most time (the "hard" parts) are often much, much easier than expected. But the savings get totally eaten up by fights with the tools, miscapitalized/mispunctuated code that takes 3 days and 4 people to detect, etc.