>>> 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.
You ju
On Mon, Nov 23, 2009 at 9:58 AM, Luc Maisonobe wrote:
> 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
>>> ou
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
Doug Bateman wrote:
> Howdy all,
>
> Tonight while browsing through the latest commons projects, it
> occurred to me the once modest commons project has grown substantially
> over time and has a lot of great stuff. There are now lots of sub
> projects. Actually, it's 37 active subprojects to be
> 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
2009/11/22 Doug Bateman :
>> It means much bigger jars. 3M jars when people complain about the
>> size of the 500k Collections jar. I think a lot of that is not the
>> size of the jar, but the ability to grok the fullness of the API -
>> anyone who actually cares about jar size should be using tool
2009/11/22 Doug Bateman :
>> It means much bigger jars. 3M jars when people complain about the
>> size of the 500k Collections jar. I think a lot of that is not the
>> size of the jar, but the ability to grok the fullness of the API -
>> anyone who actually cares about jar size should be using tool
> Raising one question: do you thing some production project could use
> latest version of project commons.A and old version of commons.B ? They
> would probably not like merging both projects into one. Is this a use
> case we want to address or is it too theoretical ?
Well, the dependencies betwe
Doug Bateman a écrit :
> Howdy all,
>
> Tonight while browsing through the latest commons projects, it
> occurred to me the once modest commons project has grown substantially
> over time and has a lot of great stuff. There are now lots of sub
> projects. Actually, it's 37 active subprojects to
On Nov 21, 2009, at 4:41 AM, Doug Bateman wrote:
> So that's the question... would it potentially be beneficial to
> consolidate some of the projects? What do we lose? What do we gain?
>
The developer community around many of the commons projects is small. Looking
at the committer lists can
Very impressive email.
With regards to JDK dependency, I would treat everything as 1.5
dependent and worry about how to handle 1.6/1,7. Lang's trunk is 1.5
and there are 3 issues that would like 1.6.
Some more/repeated issues:
* Ties release cycles together. Some major issue in one component
wou
11 matches
Mail list logo
