------------------
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
"core stuff" -------------------------- "non-core optional stuff" "no dependencies" --------------------- "many dependencies"
ie make the tree organized loosely like a gump dependency tree.
This allows us to collapse some versioning nightmares, makes it easier to build only a part of a project, and makes it easy to spot and avoid potentially circular dpeendencies.
Sloppy partitioning ------------------- A few days ago, I restructured the svn repository into four categories:
1) containerkit: the independently reusable things fortress
depends on
2) fortress: the fortress subprojects
3) components: the independently reusable things fortress does not
depend on
4) deprecated: stuff we really don't want the other projects
depending on
(and buildsystem/ and site/ as "augmented" stuff)I didn't think it through well enough -- there's a flaw in this structure: fortress depends on sourceresolve and pool, but these are in "components", not "containerkit". That's because I thought of these as more reusable components. Whoops. Incosistency.
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
3) deprecated: stuff we really don't want the other projects
depending onthe ugly bit here is that some of these components depend on fortress-meta. Maybe a good way to fix that is to use metaclass+qdox for our metadata (de)serialization.
There is more uglyness surrounding excalibur-testcase. Some of the component have tests that depend on it. That's a big TODO.
Moving stuff around -------------------
* 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.
Isn't that going to lead to more churns as components are moved between different lifecycles?
my thinking was that 'svn move' is actually a very easy way to mark things as deprecated. IE
svn copy \ -m "Save off excalibur-logger snapshot before deprecating it" \ https://svn.apache.org/repos/asf/excalibur/trunk https://svn.apache.org/repos/asf/excalibur/branches/Excalibur-Logger-Before-Depreaction
svn move \ -m "Deprecating excalibur-logger in favour of foo-logger" \ https://svn.apache.org/repos/asf/excalibur/trunk/containerkit/logger \ https://svn.apache.org/repos/asf/excalibur/trunk/deprecated/
should be very easy and efficient. However, it seems that svn is not as good at merging move changes into a locally modified copy as I thought it was. Shame.
WHy not break the hierarchy up in how they are used? (ie why not have ecm/, fortress/, instrument/ etc as base dir names)
Well, like I said above, I think its nice to have a deeper tree structure.
yadda yadda yadda
please do yadda yadda on a little more ;)
- LSD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
