Question

Our current product is based on Eclipse RCP. We are starting to have problems when we try to have our whole code base inside one eclipse workspace and we were wondering what others were doing.

Here’s our setup:

1. ~225 eclipse projects (all in trunk/project)
2. ~30 eclipse features (all in trunk/features)
3. ~900k lines of code

We are finding a few different bottlenecks:

1. SVN on Windows is dreadfully slow (tried TortoiseSVN, SmartSVN, command line svn), an update can take in the upwards of 5-8 minutes and it is only updating 10 small files. The only reasonable client is subclipse/subversive, however these have other issues and we have had some trouble with them.
2. Eclipse Refresh can take 3-5 minutes
3. Eclipse build can take 5-15 minutes

I believe that the solution is limiting the amount of projects that any one developer needs to have checked out at and active at any given time, I’m just trying to see if anyone else has any good practices/policies that have worked for them.

For instance, my first thought is to set the target platform to be the last “safe” build from the trunk and then just checkout the projects on top of that. This works, but does not tell you if you have broken any projects that depend on the project you have effectively overridden.

Another thought was to use project sets and just checkout what you need that way.

Has anyone else run into this problem? If so, what are you doing to get around it?

Thanks.

Answer 1

The policy we have adopted for this kind of configuration is one centered around the notion of deployment.

Any project is responsible for building and then versionning its set of files to be delivered (jar, war, ear, …).

That means:

• Any “integration team” in charge to test the all system can quickly update the all deliveries in one request to the VCS, without having to rebuild them all. Hence the “deployment” word: it is facilitated by this approach.

• more importantly for your question, any project only need to query the deliveries it needs to compile in order to work and make code evolutions.

So for any given project, only one is actually opened in eclipse, and it refers to various libraries coming from other projects.

That also forced us to:

• rethink our various dependencies between all the projects (detecting some case of cyclic dependencies to be removed),
• recheck our applicative architecture, when we realized that several projects were too “small-grained” and needed to be aggregated together.

---

there are basically two approaches:

• system-based, where every part of all the applications can be developed together, and where you have source dependencies on every projects you need
• component-based, where your project has no source dependencies and depends only on libraries.

On an eclipse-plugin approach, a middle-ground need to be found:
All projects from a same domain (like “com.mycorp.fileutil[.XXX]“) can be represented by eclipse projects with source dependencies between them. But any other component needed by “com.mycorp.fileutil” which is not part of that domain should be imported as a library, not as source dependency. Hence our “deployment-centric, release first” perspective.