Project layout

[Leo Simons <ls...@jicarilla.org>]

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" \
   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: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/

Re: Project layout

[Peter Donald <pe...@realityforge.org>]

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: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/