jQuery in Action, 2nd edition*
The moose likes Java in General and the fly likes project creation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "project creation" Watch "project creation" New topic
Author

project creation

Chris Montgomery
Ranch Hand

Joined: Jan 14, 2004
Posts: 141
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.

Thanks!
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41634
    
  55
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.


Ping & DNS - my free Android networking tools app
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.
Chris Montgomery
Ranch Hand

Joined: Jan 14, 2004
Posts: 141
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.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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:

Strategy s = StrategyFactory.getStrategyFor( "function" + productType );
s.execute( args );

Someplace in configuration we map product type 123 with key "function123" and value of a fully qualified classname so the factory can say

String classname = Configuration.get( key );
return Class.forName( classname ).newInstance();

The strategies are in product or user group specific projects, not core. Any of that sound useful?
 
jQuery in Action, 2nd edition
 
subject: project creation