views:

222

answers:

4

I have a legacy Java (not my native language) app that I'm trying to build in Eclipse Galileo.

As it's not my own, I can't speak to the quality of the design, but I am coming across a number of instances where I'll have something like this:

In a project called, say, "lib_a", I'll have a file containing this:

import com.acme.lib_b.onething;

Project "lib_b" on the other hand, will contain:

import com.acme.lib_a.anotherthing;

Of course, the problem is that one project can't be built because the errors prevent me from creating a .jar file that can be added as an external archive to the other project, and vice versa.

It seems to me that this must be a fairly common occurence in building Java applications. Rewriting it from scratch is not an option here, so I'd like to know "what other folks do."

+3  A: 

You can link projects in eclipse, so you're essentially declaring one project as a dependency of another, just like declaring a jar.

Project:-> Properties -> click on the "projects" tab, click "add", and you'll have the option of any open project.Additionally eclipse tracks these so that when you open "A" linked project "B" opens.

Steve B.
Not sure this would solve the errors, though.
Buggieboy
The errors are a completely separate problem - you haven't mentioned what they are!
Adrian Mouat
It will work sufficiently for loading imports. However, if your projects are really messed up, and they have conflicting imports and such things, you might be better off building a minimal jar by hand for inclusion.
Steve B.
The error is simply "import cannot be resolved."
Buggieboy
A: 

I'd just merge them as a single project.

If you cant use A without B and you cant use B without A having separate JAR files doesn't seem very useful.

Kris
+1  A: 

Maybe if onething and anotherthing aren't core parts of each project (e.g., utility classes), then you could move one into the other project to make the references one-way, or create a common util.jar.

Otherwise I would merge the projects if they are interrelated to a great extent.

JeeBee
I like the common util idea. It adds an extra step, but it would allow me to factor out problematical definitions so I can at least get one project built. The common library might even be temporary until I can reintroduce those definitions back into their original classes.
Buggieboy
+1  A: 

Basically a sign of poor design. Possible solutions

  • there are common parts in the 2 libs that should be refactored into a "common" library
  • both libraries are really 2 halves of the same library and should be combined
  • one library is relying on the "internals" of another library and some interfaces should be introduced to break this bad dependency
james