commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: Consolidating Subprojects
Date Mon, 23 Nov 2009 17:58:36 GMT
Torsten Curdt a écrit :
>> We use some commons projects in one of our commercial products that
>> uses in-browser applets. Size is very important for some of our
>> customers who have clients connecting in from geographically remote
>> outstations over links with about as much bandwidth as a piece of wet
>> string.
>> We ship the workstations with the JRE installed so that's never a
>> problem, but maintaining a connection long enough for the browser
>> download and cache all the necessary jars almost always is.
>> Note that I'm not opposed to a consolidated commons distribution, it's
>> just that you should understand why size does matter for some
>> applications.
> Sure, but how many users have that requirement? More than 1%?

Even if it is 1%, it's worth considering. I am really not comfortable
with project addressing only the 80% more frequent cases. Minority
should never be neglected. It's clearly a philosophical and personal choice.


> Someone that cares about jar sizes can easily use the right tools to
> reduce the footprint. IMO jar size should be less of a concern.
> That said I am still not sure what to make out the proposal.
> Less jar juggling - sure ...but also more dependencies of what needs
> to be fixed before a release.
> Plus (I am sure) people will be complaining that they "don't need all
> this stuff" - which is not that great from Commons' image point of
> view.
> cheers
> --
> Torsten
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message