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?

Pillowcase

What happens if you turn off Eclipse's "Build automatically"? – Liquidize

Did that, but Eclipse-build still has to be done, manually then, to make Eclipse aware of the changes. After a Maven build, Eclipse is not aware that errors have been resolved etc. – Pillowcase

The whole point of m2e is that you should NOT need to do maven builds manually, a ctrl-b should build everything you need, and the normal "run" or "deploy" mechanisms should "just work" - the eclipse way. – Rugged

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.

Tigerish

Do you think mvn eclipse:eclipse works better than m2e? – Pillowcase

On a eclipse workspace with 70 projects I think it works better. The eclipse and maven phase does not mess with each other and i can 'run' maven phase when I want to. – Ode

Yes, same here with a 100 modules project, eclipse:eclipse work fine, m2e is unusable – Buffybuford

328 modules - beat that! I am literally crying for a solution. (Yes, reducing the number of modules is one of them ... we're already on it!) – Knitter

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?

Chickadee

While these tips are nice, they're not going to save you with an m2e-enabled project with three-digit subprojects... – Tayyebeb

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.

Forb