excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <lsim...@jicarilla.org>
Subject Project layout
Date Tue, 13 Jul 2004 12:08:59 GMT
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

   "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 on

the 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" \

svn move \
   -m "Deprecating excalibur-logger in favour of foo-logger" \
   https://svn.apache.org/repos/asf/excalibur/trunk/containerkit/logger \

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 ;)


To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/

View raw message