I have 4 different projects; one for database related, one for xml/schema related using JAXB, one for web service, and 4th one is the main application. The main application depends on other three projects. I want to build all 4 independent, is that possible. for example if I change something on the database related project and I don't want to compile, the main project.
Any good IDE will let you divide your code into separate projects, store their source and binaries separately, and define dependancies between code units. What IDE are you using? Eclipse is extremely popular; I prefer the simpler interface of JCreator myself.
posted 14 years ago
Yes, I am using Eclipse and MyEclipse. Each project uses separate path for src and binaries. Right now my problem is I have to build all other three projects before building the main project. I want to build all the project independently
Then you need to create jar files from your three base projects, and let the main project depend on those instead of the projects directly.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
posted 14 years ago
Yes, and then if you want to make a change to one of the other projects, you just rebuild the jar for it so the other projects will get the latest version. This also has the advantage that you can work on changes to one project without affecting the stability of the others.
You are incurring the wrath of the dependency monster.
The fact is, if you have code in one project that directly depends upon the API of any single object in another project, then you have a project dependency and they cannot be built separately. What you really want to do is get control over your dependencies, and here's how you do that.
I have a Person object in project A which wants to communicate with another Person object, and it uses a Phone object to do so, from project B. Since Person is using a Phone instance, it has to intimately know the Phone class' API. First, pick up the phone, then wait for a dial tone, then dial a number specifically formatted for input into the phone, loop talking into the microphone and listening at the speaker until the communication is done, then hang up the phone. A highly detailed sequence of interactions that's specific to this Phone object in project B and does not apply to other forms of communication (using IM, smoke signals, semaphore, etc). Furthermore, I cannot build project A unless project B is already built, even if Phone is the only object I use in all of project B. I've created a directional project-level dependency from A to B because of this usage of Phone's API.
Furthermore, it might turn out that to get Phone to compile, it has dependencies all throughout project B. It depends on all sorts of objects in project B, so what this boils down to is: if there's a single problem in any one part of the entire project B, and it doesn't build, I can't build A.
Here's how to fix it. Project A should define what it needs from a communication device API and define an interface. This interface belongs in project A and any two Persons in project A can use it. This API might look like this:
This is off-the-cuff as an example--in a real system it would probably make sense to build it out quite a bit more (for instance, instead of blocking to wait for a response from sendMessage(), it might make more sense to register a listener and receive the responses asynchronously). In any case, this API is defined based upon what the Person object needs from a communication device.
Then, Phone, in project B, can implement this interface. Now, project A doesn't depend on project B, but the other way round. Is this any better? Well...yes and no. Now you can compile project A without B, but not B without A...on the other hand, B is much easier to compile because it doesn't depend on any actual *code* from A, only an interface with no code (and therefore not likely to contain any bugs). Furthermore, project A could package up this interface (and all such interfaces implemented in B) into a jar file and build that jar separately and provide it to project B. This would be called an "SP" jar ("service provider"), so-called because it provides a set of APIs to a service provider (project B) to be implemented.
Or, you could allow the Communicator interface to be in project B, and have B package up all such interfaces separately in a jar. This kind of jar would be called a "client" jar, so-called because it is provided to all clients of B. You might say that in the previous case of an SP jar, A was providing a kind of client jar to B, so what's the difference? You'd be correct...but an SP jar is a specific kind of client jar. It simply denotes the roles of the two projects. In the former case, B is providing a service to A by implementing APIs controlled by A (specified in the SP jar). In the latter, B is in control of and owns the interfaces (specified in the client jar), so it's not implementing a service requested by A.
Or, you could make the interface a completely separate project altogether, project C. Now, both projects A and B depend upon project C, but project C consists of nothing but interfaces--it has no code whatsoever so it's nearly guaranteed to build. In this case, the only output of building project C is to generate a jar (or jars) with highly abstract APIs in it. With this approach, project C plays the role of a specification (or perhaps a "protocol", depending on whether it contains interfaces that define what each project does, or simply the communication between the two projects).
Regardless of what approach you use, you are very wise to recognize that dependencies between projects are something that must be carefully controlled.
For more information on these ideas, read the following articles in this list: Stability and the Dependency Inversion Principle.
I was born with webbed fish toes. This tiny ad is my only friend:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop