Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <408BEB6C.5090105@steitz.com>
Date: Sun, 25 Apr 2004 09:46:36 -0700
From: Phil Steitz <phil@steitz.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [general] library management Was: [lang] Markup stuff on lang???
References: <20040419201836.31C511A41@umbongo.flamefew.net>
 <Pine.LNX.4.44.0404242133500.21670-100000@umbongo.flamefew.net>
 <408B700A.5030202@apache.org>
In-Reply-To: <408B700A.5030202@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


matthew.hawthorne wrote:
> Henri Yandell wrote:
> 
>> So, after Commons-1.0's release, Commons-Collection-1.0.jar would have
>> been spun off and Commons-2.0 would not have contained that jar.
>> Collections-1.0 may even spin off another project, primitives, functors,
>> collections-weird or whatever, but they must do it by sending that code
>> back to Commons-2.0, not by having it become its own new project.
> 
> 
> 
> With the proposed system, I'm pessimistic that even a 1.0 release would 
> ever happen.
> The required amount of coordination between projects just seems impossible.

I agree.  Another consequence of code fragmentation is test and 
documentation consistency.  Pulling things apart and recombining would 
make maintenance of tests and documentation a major PITA.
> 
> It it an interesting idea, but what would happen the first time that I 
> need something in
> the commons-collections CVS HEAD?  I'm confused how the development of 
> individual
> commons projects would coincide with the politics surrounding the 
> communal releases,
> which basically just points back to my original statement.
> 
> A part of the problem that it seems you're trying to solve is the 
> infamous "too many jars".
> Maybe I'm just being stubborn, but I don't feel that I've ever heard a 
> coherent
> argument as to why this is an actual problem and not just somebody's 
> preference.

I don't know the answer to this, but I agree that we have never reached 
anything close to a consensus on this subject and I suspect that it really 
does come down to user preference and characteristics of the user 
environment.  We should take discussion of this topic to the user list.
> 
> If commons is guilty of anything, it's probably just being a little 
> loose with inter-project
> dependencies.  The digester-collections situation which has been 
> discussed lately is
> a perfect example where cut-and-paste would have probably been a better 
> solution.

Another hard problem.  Cut-and-paste is appealing, but is essentially 
forking and has some drawbacks, including:

1) If you care about tests and documentation, you need to hack in and 
maintain the associated tests and docs as well
2) If you decide at a later time that there is more in the source package 
that you want / need, you may be SOL
3) Forking / fragmentation fragments eyeballs

The last item above points to a whole range of community issues that makes 
me think that we are better off defining and maintaining a stable set of 
reasonably scoped components.  While some Commons components are indeed 
"large," it is still possible for both developers and users to learn their 
way around even the big ones (e.g. [collections]). This has lots of 
benefits that we (both users and developers) would lose if the components 
effectively lost their individual identities.  Obviously, the hard part is 
in defining "reasonable scope," and managing the size-dependencies 
tradeoff, but I don't think that the answer is to throw in the towel and 
drop the idea of individual Commons components.

Just my HO.  Could be I am missing Hen's point.

Phil
> 
> How does everyone else feel?  Does commons have an actual problem with 
> releases
> and packaging?
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org