forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: SVN reorg: take 2
Date Mon, 01 Nov 2004 14:45:55 GMT
Dave Brondsema wrote:
> 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 
> Forrestbar and logos are independent tools.


This is also why I had reservations in keeping forrestbar in Forrest, 

As for logos, my intention is to integrate it as a plugin, and 
forrestdoc also.

> Forrestbot could be, if someone wrote a different "build" workstage.

Could be but should not be. the day it became an indipendent tool, it is 
not part of Forrest anymore.

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

I understand what you mean, but they will be doing it for a specific 
version of Forrest, and that is where they should take it from.

Maybe you want t multi-jar release? One thing is doing separate releases 
(in time), and another doing a single release of separate packages.

>>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?  

Only because of political & developer structure. It has been an utter 
failure socially, and is one of the prime reasons Avalon collapsed so badly.

> I see value in having
> subprojects have their own src, docs, build directories. 

Please explain.

> I do think the Forrest TLP should remain united politically and
> developmentally.

As I see it, history has showed that making indipendent subprojects 
leads in one way or the other to fragmentation. Communities change, 
people come and go, and separating areas creates fragmentation that 

> 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.

Is this something you actually forsee or just a possibility that you 
want to take into account? For the latter we can always refactor later on.

> Webservices, portals, logging, tcl, DB, and others are umbrella projects also. 
> Ant has an antidote subproject.  Are they too planning to break up?

Webservices projects are too small to break out. Portals are actually a 
couple of projects. Logging is the same project in different languages. 
DB is basically only OJB and tcl was created much earlier. Antidote is dead.

We had a discussion at Apache a year ago, and the result was that 
umbrella projects are not the future. AFAIK IIUC it's the current view 
of the board also now.

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

Avalon was basically the samme project built in components, and each 
component had become a feud. I'm scared to death in seeing it repeated.

>>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. 

Let's not solve things too early.

> Some of our tools should be able to be
> downloaded, built, and used without forrest itself.

Let me ask you a question: have you ever used forrestbar?
Better: all Forrest developers that have used it raise your hands.

Same question: forrestbot?

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message