commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [configuration] Plan for 2.0
Date Tue, 11 Sep 2012 19:27:35 GMT
Am 11.09.2012 00:08, schrieb sebb:
> On 10 September 2012 20:33, Oliver Heger <oliver.heger@oliver-heger.de> wrote:
>> 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?
>
> Not sure it's necessary to wrap all 3rd party library APIs, just don't
> expose their classes in the Configuration 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.
>
> If you update Configuration to use lang3, then the custom
> implementation will break anyway - unless Configuration is updated to
> work with both Lang and Lang3.
> Do you really want that? Does not seem scalable.
>
> If custom classes in future have to implement a Configuration
> interface, rather than something from Lang, then at least the custom
> class is then only dependent on the Config. API.
>
> Whatever happens, custom classes are going to need to be changed if
> support for Lang is dropped in favour of Lang3.
>
> Or am I missing something here?

Yes, sure, client code will be affected by this change.

>
>> Not sure how to deal with this issue in general.
>
> Once the API dependency on Lang is removed, it won't be an issue.
>
My point was if we use functionality from a library like [lang] to 
implement concepts in [configuration], it might be natural to somehow 
pass objects from this library to [configuration] objects. Then they 
become part of the public API of [configuration]. Avoiding this will 
take some effort and may be less straight-forward from a user's point of 
view.

Oliver

>> 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


Mime
View raw message