forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: svn commit: rev 56151 - in forrest/trunk: . etc etc/applied_patches etc/cocoon_upgrade forrestcore forrestcore/etc forrestcore/lib forrestcore/src/core forrestcore/src/core/bin forrestcore/tools/ant forrestcore/tools/dtdconverters forrestcore/tools/jetty forrestcore/tools/targets lib lib/core lib/endorsed lib/optional tools/ant tools/ant/bin tools/ant/lib tools/dtdconverters tools/jetty tools/targets
Date Sun, 31 Oct 2004 22:49:24 GMT
Dave Brondsema wrote:
> Nicola Ken Barozzi wrote:
>> Are the other moves not ok? IMHO they are a natural part of the 
>> restructure we voted, that's why I'm doing it.
> Nobody mentioned legal, lib, etc, or ant in the restructuring threads.
> I had understood the restructuring to be so that our subprojects could 
> be independent of each other

I disagree in part. See below.

> , and your changes are reverting that.  As a 
> TLP we can be composed solely of related subprojects (like XML or 
> Jakarta does) with no master project.  

Again I disagree. Jakarta and XML are an old example of umbrella project 
that is being abandoned. Forrest for example is not under XML anymore.

> Some advantages to this would be:
> * seperate, smaller releases (we can still do one giant release if we want)
> * you can check out just "forrestcore" from SVN or just "forrestbot" for 
> example, and keep the others at a stable release
> * easier to manage jar dependencies (what if subprojects need different 
> versions?)

You can still do the above. What of the current move makes the above 

(Note that the change is not complete, and I still have to put in the 
code to have each subproject explicity define the jars needed)

> * common files at the top of our SVN tree instead of within subprojects 
> can be confusing, especially if they don't relate to some subprojects

Do you refer to etc only or also other parts?

> Disadvantages:
> * some jar files will be duplicated within subprojects
> * some subprojects do depend on files from forrestcore.  Using 
> $FORREST_HOME to locate it should work, but might be a pain sometimes.

My reasoning was to eliminate these disadvantages, and on the fact that 
we had said that we wanted a single bin dir with a single forrest script.

I'm sorry that I am causing confusion, probably we have not been clear 
enough in defining all the moves to do. I'm sure that in a couple of 
mails we can have the best solution.

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

View raw message