Many applications rely on a single class-loader.
Not all applications can easily be changed to use multiple
classloaders, and anyway I don't think Commons should force end-users
to use multiple class-loaders to fix compatibility issues.
Since a single class loader can only load a single instance
>> Why are you using the jars from the app server would be my question.
>
> * Because I wouldn't want to modify the installation?
> * Because I'd like to deliver my application to customers so that they
> can deploy in an unmodified environment?
> * Because it works fine that way with the current p
On Tue, Apr 19, 2011 at 3:41 PM, Torsten Curdt wrote:
> Why are you using the jars from the app server would be my question.
* Because I wouldn't want to modify the installation?
* Because I'd like to deliver my application to customers so that they
can deploy in an unmodified environment?
* Bec
>>> * source compatibility for x.*.*
>>
>> Disagreed. I can quote numerous examples of application servers that
>> come with varying versions of commons-foo, even within my employers
>> house. Your proposal would mean that I had to create varying jar files
>> of the applications shared library, dep
On 19 April 2011 09:33, Jochen Wiedmann wrote:
> On Tue, Apr 19, 2011 at 10:16 AM, Torsten Curdt wrote:
>
>> * source compatibility for x.*.*
>
> Disagreed. I can quote numerous examples of application servers that
> come with varying versions of commons-foo, even within my employers
> house. You
Jochen Wiedmann wrote:
> On Tue, Apr 19, 2011 at 10:16 AM, Torsten Curdt wrote:
>
>> * source compatibility for x.*.*
>
> Disagreed. I can quote numerous examples of application servers that
> come with varying versions of commons-foo, even within my employers
> house. Your proposal would mean
On Tue, Apr 19, 2011 at 10:16 AM, Torsten Curdt wrote:
> * source compatibility for x.*.*
Disagreed. I can quote numerous examples of application servers that
come with varying versions of commons-foo, even within my employers
house. Your proposal would mean that I had to create varying jar file
With a version of x.y.z I think it would be sane to expect...
* binary compatibility for x.y.*
* source compatibility for x.*.*
* no compatibility whatsoever for *.*.*
* but *.*.* releases should not clash
I don't think we should cater for any other kind of user stories. If
it's a user wants to u
On 18 April 2011 21:40, Henri Yandell wrote:
> On Mon, Apr 18, 2011 at 1:35 PM, Daniel F. Savarese wrote:
>>
>> I guess I had more to say, or rather ask.
>>
>> In message , sebb writes:
>>>really necessary, because of the additional work that it causes all
>>>downstream users.
>>
>> What addition
Daniel F. Savarese wrote:
>
> I guess I had more to say, or rather ask.
>
> In message , sebb
> writes:
>>really necessary, because of the additional work that it causes all
>>downstream users.
>
> What additional work? As far as I know, end users--as in people who don't
> write code--don't do
On Mon, Apr 18, 2011 at 1:35 PM, Daniel F. Savarese wrote:
>
> I guess I had more to say, or rather ask.
>
> In message , sebb writes:
>>really necessary, because of the additional work that it causes all
>>downstream users.
>
> What additional work? As far as I know, end users--as in people who
On 18 April 2011 21:03, Daniel F. Savarese wrote:
>
> In message , sebb writes:
>>If binary compat. is to be broken, then it needs to be done once, and
>>done properly so it does not have to be done again. That's not
>>something I personally have any inclination to tackle at present, so
>>I'm tryi
On 15 April 2011 20:34, Daniel F. Savarese wrote:
>
> In message <-2240415941472220542@unknownmsgid>, Gary Gregory writes:
>>If your are going to break binary compatibility then a major release
>>is the time to do it. Is there any question that the design is wrong?
>
> I got the impression the cha
If your are going to break binary compatibility then a major release
is the time to do it. Is there any question that the design is wrong?
Gary
On Apr 15, 2011, at 10:49, "Daniel F. Savarese" wrote:
>
> Prior to the 3.0 release, I'm trying to review recent code changes and
> test the code in wh
14 matches
Mail list logo
