I'm working on a java application that was written for one partner, but could easily be used by many partners.
I'm currently involved in a discussion regarding approach to handling additional partners.
One school of thought is to create a core project, which contains the common "stuff". Then for each new partner, create an entirely separate project that has the "core.jar" as one of its libraries.
The other school of thought is to have only one set of code and create partner specific packages to organize partner specific code. Then let Ant manage the rest (so your jar file doesn't get huge over time).
I kinda like the first one, but don't have a reason not to do the second other than I don�t understand Ant well enough to follow through with the second option.
I already have a feeling that this is an "it depends" kind of question, but would still love to hear what others have to say.
Joined: Mar 22, 2005
Can you give us any idea what "partner-specific" means? Do partners develop code? Do they use different functionalities? Are there different personalizations for them? It's not clear from the post what you're trying to achieve.
You might enjoy the package design ideas in this blog by Robert Martin. Here he means "package" as all the stuff you'd need for one partner, not just a simple Java namespace.
In Eclipse (assume that's the kind of projects you mean) I'd try for one core project and another for each partner. I'd build a jar per project and deliver each partner only the core and their own jar.
It's key that your core project never references any of the partner projects. Google for "dependency inversion" and "dependency injection" for neat ideas on how to accomplish that. My own tiny contribution is Here.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jan 29, 2003
Hey, Chris, keep us posted on how this goes! It's a very neat problem. And scroll down to the UML, OO, etc. forum where we talk design stuff like this until we run out of breath.
Joined: Jan 14, 2004
Thanks for the comments. Sorry I couldn�t get back sooner � was on vacation�
To clarify "partner specific", let's say you have a Member class and one of the methods in this class is addMember(). All partners want your name and address, but only one wants your wedding date. The code to gather wedding date is partner specific.
Either in your new namespace, or project, you would create a new class that extends class Member to gather the wedding date, rather than adding it in your core class. Once you start down that path, you have to incorporate switch statements and potentially duplicated code to handle each partner�s unique needs as well as common needs.
One [Eclipse] Project vs. Many � Here�s what was unearthed�
You can accomplish the same thing using both approaches, however with a single [Eclipse] project, all of your coders need to be on the ball and risk management is high (see Stan�s links).
The other major risks for us lie in the config files. If everything is in one project, you need to be careful when creating/running a build so you don�t accidentally include the wrong partner�s config files. You can create unique builds per partner and even name the jar whatever you want to avoid these types of accidents.
New hires/consultants need your entire source to do any sort of work on a particular partner. You are exposing ALL of your code to strangers!
Another thought was if you are in a market where you could sell your source code to your partners, then you have a little mess on your hands trying to get just the partner specific tree and core. If you have a case of dependency inversion, you are in an even deeper mess
I definitely prefer separate projects. There is simply less to baby-sit. However, it appears to be only a matter of preference.
Joined: Jan 29, 2003
My project is in exactly this situation except (ok it's not exact then is it) we deploy the whole shootin match every time. Still, we keep product and user group code out of the core, including switch statements based on product or group info. We have a lot of code like this: