Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <504E4086.9000601@oliver-heger.de>
Date: Mon, 10 Sep 2012 21:33:26 +0200
From: Oliver Heger <oliver.heger@oliver-heger.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
 rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [configuration] Plan for 2.0
References: <504A4F03.90109@oliver-heger.de>
 <CAOGo0VbCJ13QJcYerCmqbhKDMLsbzBizLON5oPBex2C0uvv=uQ@mail.gmail.com>
 <504B5A0B.4020201@oliver-heger.de>
 <CAOGo0VaepRFfCEQqu9y2zVxRQP2q+nhkWf5ZmcTcn=wO6boRxg@mail.gmail.com>
In-Reply-To: 
 <CAOGo0VaepRFfCEQqu9y2zVxRQP2q+nhkWf5ZmcTcn=wO6boRxg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Am 09.09.2012 14:26, schrieb sebb:
> On 8 September 2012 15:45, Oliver Heger <oliver.heger@oliver-heger.de> wrote:
>> Am 08.09.2012 03:44, schrieb sebb:
>>
>>> On 7 September 2012 20:46, Oliver Heger <oliver.heger@oliver-heger.de>
>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> the pom was updated to make 2.0-SNAPSHOT the current development version.
>>>> This means we are free to implement major changes without having to
>>>> enforce
>>>> binary backwards compatibility.
>>>
>>>
>>> BC breakage will require package and Maven coordinate changes at some
>>> point just before release.
>>
>> Yes, I am aware of this.
>>
>>
>>>
>>>> The question is: What are the goals for version 2.0? I would recommend to
>>>> define a clear focus so that the next release will not take too long.
>>>> Obviously there are already people waiting for a [configuration] version
>>>> compatible with [lang3].
>>>>
>>>> Some points I have in mind are the following ones:
>>>> - Switch to [lang3]. This is the main reason for going to version 2.0
>>>> because this cannot be done in a binary compatible way.
>>>
>>>
>>> Not sure I follow that.
>>> Why would changing a dependency affect the API for Configuration?
>>> Does not make sense to me.
>>
>> Some classes of [lang] are exposed in the public API of [configuration]. For
>> instance, variable substitution in configuration files is done by a
>> org.apache.commons.lang.text.StrSubstitutor object. The StrSubstitutor to
>> use can be set. So switching to [lang3] will effectively change the public
>> API of [configuration] in an incompatible way.
>
> That seems very fragile. There has to be a better way to handle that.
>
> Fixing it will break the API (once), but at least the API will then be
> stable, regardless of what happens with LANG.

Do you mean all interfaces or classes from 3rd party libraries should be 
wrapped so that they do not leak in the public API?

I agree that using 3rd party classes in the public API is obviously 
fragile and should be avoided as much as possible. But I am not sure 
whether a radical wrapping approach works in all cases.

Also, it might make reuse of classes harder for client code. Take for 
instance the StrSubstitutor example. A client may already have a custom 
implementation to be used with the corresponding [lang] classes. Now 
this implementation cannot be used together with [configuration] because 
here a slightly different interface is required - although the 
functionality is the same.

Not sure how to deal with this issue in general.

Oliver

>
>> Oliver
>>
>>
>>>
>>>> - Improve thread safety and concurrent implementations in general.
>>>> - Rework reloading. This is related to the previous point because I think
>>>> the tight coupling of the current reloading implementation is one of the
>>>> root causes making the implementation of thread-safe configurations so
>>>> hard.
>>>> - Have a look at older Jira tickets which have been postponed because
>>>> they
>>>> would break binary compatibility.
>>>>
>>>> Any other points, wishes, or opinions? We should discuss the points
>>>> separately when it comes to their implementation.
>>>>
>>>> Oliver
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org