commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: [combo] Commons Core release?
Date Thu, 14 Aug 2003 12:52:29 GMT

Howdy,
Since we all agree a combo jar, if it existed, would not replace the
individual releases, perhaps we should try a revolutionary way to gauge
the usefulness of this combo jar: ask the users.

How about we start a thread on commons-user and ask users what they have
to say?  How many would find it useful, etc.  Given that many commons
users are developers themselves, their insight would be useful IMHO.  If
no one wants it, why do it? ;)

I for one wouldn't use such a combo jar, because I like picking able to
pick and choose versions and have only what I need.  Yes, a 4MB combined
jar isn't that big, but it's a lot bigger than the 400K or so of commons
jars I really need ;)

Yoav Shapira
Millennium ChemInformatics


>-----Original Message-----
>From: Henri Yandell [mailto:bayard@generationjava.com]
>Sent: Thursday, August 14, 2003 8:23 AM
>To: Jakarta Commons Developers List
>Subject: Re: [combo] Commons Core release?
>
>
>
>On Thu, 14 Aug 2003, Tomasz Pik wrote:
>
>> Henri Yandell wrote:
>> >
>> > I figured the munging would be unlikely to pass muster. The easy
>solution
>> > is that BeanUtils/Net are not allowed into a combo-distribution
until
>> > their dependencies are. So ORO/commons-logging would have to be in
it.
>One
>> > problem there is commons-logging's dependency on log4j, logkit and
>> > avalon-framework.
>>
>> Two points here;
>> 1. here was a disussion of splitting logging into 'api' and
>>   implementation jars but I don't know what's with this idea;
>> 2. it's compile-time dependency rather then runtime;
>> I'm also concerned about recompilation of the code.
>> Note that official release of component comes in source and
>> binary (compiled) version. And sometimes recompilation may
>> make code different (OK, I know, in most cases it's J2SE1.4
>> problem with StringBuffer.append(StringBuffer) but...).
>
>Yep. Splitting proejcts up is the way to handle such things. With an
>implementation version that does not depend, another one dependent on
>jdk14 in this instance etc.
>
>Combo builds against cvs tags, so as long as the same compiler is used
>things are fine I think. The problem there is that choice of compiler
is
>not defined in Commons. Not really a Combo issue as such but a
>cross-Commons issue. Possibly release builds should all occur on some
>standard machine [nagoya or something].
>
>Hen
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org




This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.


Mime
View raw message