I define a project as an SVN directory containing trunk, branches, tags sub dirs.
What criteria do you use when determining when to split a project into two or consolidate several projects into one? - One App per "Project" with a shared projects for common source and resources? - One big "project" containing all source and resources for the app?
Single project or multi project both have their pluses and minus. We are heading more towards a single project and I'm trying to figure out if this s the right approach.
Split projects allow greater ability to control how different parts of the suite incorporate a change. The common library can be version and different applications can chose to use a specific version (maven dep management approach).
Split project also create multiple class hierarchies making the code more difficult to understand as a whole and potentially leading to code duplication. I would assume that proper design of the overall structure and the relationships between components would be key to managing this cost.
A unified project approach will make it easier on the developer in terms of setting up a workspace, and provide a single class hierarchy. This is a double edged sword as it will also throw much more information at the developer (too many classes to comprehend).
So, when you are trying to decide where to combine and where to split, what rules of thumb do you use?
Thanks for the input. I won't "choose" an answer because I think all have valuable points in them. Avoiding premature optimization does seem key as does keeping the layout as simple as possible for the time being. We are moving to a single project containing the apps because 90% of the time we release ALL together. Therefore, to complicate matters with a one-apps-per-project doesn't seem to make sense. Even when we go to maven it is likely that all maven artifacts for a given version will be made from the same branch. We can always change it later if need be using SVN history and fisheye to keep us sane.
We'll refactor the source layout just like we'd refactor the source. When a project starts to "smell bad" from a girth and dependency situation we'll break it up, but not before that. I'll probably use girth in time not girth in space: time to build & test, time to checkout. If I have a 1GB tree that I can checkout in < 10 minutes and build/test in < 30 minutes I don't really need to break it up unless I am required to release parts of it frequently.
So, thanks for the input. It was really helpful in my framing the question for me team and evaluating options.