>>> 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
On Mon, Nov 23, 2009 at 7:24 AM, Phil Steitz wrote:
> As
> Torsten pointed out, the difficulty managing "multi-releases" is
> also not to be underestimated. IMO we do not do as good a job as we
> should releasing often and early in Commons and I would be hesitant
> to make a change that made that
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
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 exact. Plus the
archived projec
13 matches
Mail list logo
