forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <>
Subject Re: SVN reorg: take 2
Date Mon, 01 Nov 2004 14:26:42 GMT
Quoting Nicola Ken Barozzi <>:

> The first reorg ahs been needed but is not enough. Other dirs need 
> placement and have not been yet discussed, and we need to define the 
> subproject development. I have started, but let's talk about it here 
> before I continue: below are the points.
> 1 - Forrest projects are not indipendent
> We are delivering a single product called Forrest, that is internally 
> composed of subprojects. Our release cycle is based on this product; 
> however we may have interim releases of subprojects in case it's deemed 
> necessary.

Forrestbar and logos are independent tools.  Forrestbot could be, if someone
wrote a different "build" workstage.  Editor configurations, like the one for
XXE, are independant also.  Use case: document writers/editors install and use
the XXE configuration to do their document writing, and save/commit changes to
their documents.  They never run forrest, that is done on a elsewhere (perhaps
part of forrestbot or doco or something).

> 2 - We are not an umbrella project
> Umbrella projects are dying at Apache. Jakarta and XML have spun off 
> many projects and are still doing so: we are one of them  :-)
> This means that we must not reconfigure ourselves to be an umbrella 
> project, and we must strive to remain unite.

Is the umbrella structure a problem because of the political & developer
structure or because of the source code structure?  I see value in having
subprojects have their own src, docs, build directories.  I do think the Forrest
TLP should remain united politically and developmentally.  We also need to be
prepared for a tool subproject to suddenly grow rapidly and have to seperate
cleanly from forrest and become its own TLP.

Webservices, portals, logging, tcl, DB, and others are umbrella projects also. 
Ant has an antidote subproject.  Are they too planning to break up?  I think if
the subprojects are topically related it can work fine.  (XML and Jakarta house
many subprojects and are technologically related but not topically related).

> 3 - We shall have a single bin dir
> 4 - Move the main documentation under the forrest root

> 5 - have a single jar repository + no legal dir

> 6 - Refactor forretcore

I like all of these.

I see value in having a one single project, but my primary concern is that it
will eventually become too big.  Some of our tools should be able to be
downloaded, built, and used without forrest itself.

Dave Brondsema : : personal : programming : student org 

View raw message