Saturday, August 22, 2009

Using Eclipse With Large Code Bases, Part III

In Part II, we saw how to use links to break a large single-rooted source tree into separate Eclipse projects.

In those examples, the packages didn't have mutual dependencies--they were a directed, acyclic graph.

But in my project's legacy code base, there is another complication:

4. Packages and layers have mutual dependencies (for example, business logic in the UI layer), but Eclipse treats cycles among projects as compile errors

Of course, it would be better not to have cycles, but in a legacy code base it's not always easy, or even tractable, to remove them. Remember that my project has to work with this constraint:

6. None of this can be changed, at least not any time soon

So, a more realistic example has child1 depend on child2, and vice-versa:
package com.parent.child1;

import com.parent.Parent;
import com.parent.child2.Child2;

public class Child1 extends Parent
{
private Child2 child2;
}

package com.parent.child2;

import com.parent.Parent;
import com.parent.child1.Child1;

public class Child2 extends Parent
{
private Child1 child1;
}
This is allowed by Java, but not allowed (by default) by Eclipse for packages in separate projects, even after adding the project dependencies:



Fortunately, Eclipse allows cycles to be a warning instead of an error:


Unfortunately, that just converts the errors into warnings, which clutter the window (we already know we have cycles):


Fortunately, Eclipse supports filtering out specific warnings. In the Problems window, click the down-arrow icon on the right (View Menu), select Configure Contents..., and add a filter:


And now the Problems window is empty.

Part IV describes how we fixed this remaining issue:

5. JAXB is used to generate some .class files into a runtime directory "rt", but that same directory contains all of the .class files for the system

No comments:

Post a Comment