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>
Mime-Version: 1.0 (Apple Message framework v613)
In-Reply-To: <002601c4309f$0e799980$16939b51@oemcomputer>
References: <Pine.GSO.4.44.0404221535410.11129-100000@shell3.shore.net>
 <20686624-9496-11D8-8A5B-000393DB559A@coredevelopers.net>
 <4089DFF7.9000705@apache.org>
 <A91049E2-9C72-11D8-BC00-003065DC754C@blueyonder.co.uk>
 <002601c4309f$0e799980$16939b51@oemcomputer>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <29F2954E-9CD1-11D8-BE12-003065DC754C@blueyonder.co.uk>
Content-Transfer-Encoding: 7bit
From: robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>
Subject: Re: [collections] Size and scope issues
Date: Mon, 3 May 2004 08:11:57 +0100
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>

i definitely agree that one jar is the best solution for many users. 
for those users for whom jar size is a big issue, then i'd say for that 
for many use cases rolling a custom version (possibly repackaged) is 
the best approach. (i have heard that this is how BEA re-uses the 
commons logging stuff.)

but we've been hearing that for some users - many of them influential 
open source developers - this approach is unsatisfactory. one of the 
main aims for jakarta commons was to facilitate re-use of library code 
between open source projects. there are a few of ASF projects who are 
refusing to use any jakarta commons components on principle now for 
this reason. (they want small, tight libraries.) i suspect that this is 
partly political but there is a kernel of truth in the criticisms. it's 
best to think about this kind of issue early before a momentum 
develops.

certainly, i'm keen to see digester 2 (if and when it comes along) 
factored into a small core with minimal dependencies together with 
optional extensions. the binary distribution would contain both a 
single complete jar and a set of multiple jars. i hope that this should 
be able to satisfy most users and since this is just a build issue, i 
suspect that the maintenance would be minimal.

- robert

On 3 May 2004, at 00:41, Stephen Colebourne wrote:

> So what problem are we solving? Adding extra jar files alongside the
> complete built one creates classpath problems for users, an old 
> version of
> the 'all' jar overriding a later version of the 'part' jar or vice 
> versa.
> General chaos and confusion.
>
> People so have the ability to build their own jar files with just the
> classes they need.
>
> Oh, and I'd also suggest that more jar files does involve more work
> (maintaining and releasing), and there's a distinct lack of active
> committers on collections as it is ;-)
>
> Stephen
>
>> On 24 Apr 2004, at 04:33, Craig R. McClanahan wrote:
>>> A neat ideal, but perceptions of "really common" versus "rarely used"
>>> seem to be awfully personal.  Kinda reminds me of earlier commons-dev
>>> discussions trying to create a "commons core" JAR that included all 
>>> of
>>> the "really common" commons JARs, and none of the others.  Needless 
>>> to
>>> say, there was no consensus on what the contents should be :-).
>
> From: "robert burrell donkin" <robertburrelldonkin@blueyonder.co.uk>
>> i wonder whether it might be possible to separate out a core jar
>> containing just the basic interfaces and then split the 
>> implementations
>> into several themed jars. i still think that this should be in 
>> addition
>> to releasing a single jar containing everything, though.
>
>
>
> ---------------------------------------------------------------------
> 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