How to work efficiently with large Maven-project workspace in Eclipse?

Question

I'm working on a large multi-module Maven-based system, with some 20 sub-modules and an additional small number of project-external dependencies that are also Maven projects in my Eclipse workspace. All in all, there are some 30 projects in the Eclipse workspace.

The projects are all imported maven projects with m2e, and we use Subversion (with Subversive plugin) for source control. Eclipse is a recently updated Kepler.

My workstation is quite capable, with 4-core Intel i7 CPU, 16 Gb RAM, and a solid-state disk.

The problem is that Eclipse is very slow when it comes to:

1. Team synchronize and conflict resolution. Each time I fix a conflict and "Mark as merged", I have to wait 10-30 seconds for Eclipse to refresh workspace etc. Not to mention that the conflict-mode tree view then clears entirely, so I have to select outgoing mode then conflict mode again to re-populate. Twice - because it clears when I save the resolved source file, and then again when I mark as merged.

2. Building. I use Maven launch configurations to do Maven builds. But for some reason, doing the Maven build is not enough for Eclipse - it then has to do its own build too of the entire workspace, which takes at least as long, and much longer when Eclipse decides to hang a few minutes on 'Clearing output folder of project xxx', for several of the projects.

The result of all this is that often it takes over an hour to update from source control, resolve conflicts, build and be ready to run or continue development.

Me and my co-workers often feel that Eclipse is hampering development, when it should be enhancing it.

Is there anything that can be done to reduce the eternal waiting-for-Eclipse syndrome?

Answer 1

We have this same problem.... 72 projects in our workspace normally makes using m2e impossible. We're trying to not use m2e and start maven executable as an external tool with some configurations. And you can make maven generate your .project and .classpath to change the eclipse configurations:

mvn eclipse:eclipse

Not the best option, but is what we have now.

Answer 2

Some good tips I'd suggest are:

1. Before you start importing large projects, go to Projects and uncheck Build Automatically
2. Import projects in the smallest sub-components you can. If the project is Mavenized, this means selecting the lowest pom.xml in the tree to import each time, rather than importing a large parent POM and all it's sub-projects.
3. When you are not working on (as in, modifying) the source code of a specific project, close it by right-clicking and going to Close Project. This will release resources for Eclipse to use elsewhere. If you still need to see the source code of something without modifying it (for debugging), you can add source containers as you need
4. Use different workspaces for different projects. Eventually it's quicker to have 2 working, fast versions of Eclipse than one huge slow one

If you can't split a project, you can also try to give Eclipse more memory, and make sure you're using JVM 8, for example

-Dosgi.requiredJavaVersion=1.8 -Xms512m -Xmx2g

It sounds like you're just dealing with something that's too large for most any IDE, but that may not be the case. If all else fails, why not try IntelliJ to see if that works better for you?

Answer 3

Guys I had the same problem but instead of using IDE's for brute force build can you analyze the design of those applications properly? I'm telling that because there are applications which don't have to be entirely build, you can deploy it separately and analyze it in modules. Most of times, there aren't reasons for keeping together thousands and thousands of classes, build it and keeping it together... the IDE's like Eclipse wasn't designed for such tasks but for local developments and the servers do the integration build, not the workstations. Probably your design or your philosophy of continuous build are somewhat misunderstood.

Cya.