Leo Simons wrote:
Build partitioning
------------------
When working with multiproject builds, I've found it very advantageous to not use a very flat directory structure, but actually partition up into several small directories, ie a deeper structure. I believe a useful strategy is to split things up along the axis of
I have learnt almost exactly the opposite. You can not force dependency structure by where a source tree lives.
I still think we should split up the repository into a few categories. I guess it maybe is better to just have
1) components: the independently reusable things 2) fortress: the fortress subprojects
Why is not fortress a component? It is an "independently reusable things". At what point does a component get migrated up?
I will say again that I think that it is best to group code trees based on what elements will be worked on in concert. To reiterate the main groups I see being "ecm", "fortress" and "instrument".
3) deprecated: stuff we really don't want the other projects
depending on
Deprecated code should be archived up tagged and removed. We do not want excaliburs svn repo to act as a dumping ground for dead code.
* Why separate out deprecated elements?
The rationale is that you can
cd components maven multiproject:install
and make sure you're not using any deprecated materials.
That is not true. The deperecated components will be sucked from local repo anyways so this makes no difference.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
