On 11 September 2012 20:27, Oliver Heger <oliver.he...@oliver-heger.de> wrote: > Am 11.09.2012 00:08, schrieb sebb: > >> On 10 September 2012 20:33, Oliver Heger <oliver.he...@oliver-heger.de> >> wrote: >>> >>> Am 09.09.2012 14:26, schrieb sebb: >>> >>>> On 8 September 2012 15:45, Oliver Heger <oliver.he...@oliver-heger.de> >>>> wrote: >>>>> >>>>> >>>>> Am 08.09.2012 03:44, schrieb sebb: >>>>> >>>>>> On 7 September 2012 20:46, Oliver Heger <oliver.he...@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 Yes, but that is worthwhile if it reduces the end-user workload either now or in future maintenence. Maybe it would be possible to use a service provider interface style configuration? > and may be less straight-forward from a user's point of view. Binding the Configuration API to the Lang API means that updating to Lang3 forces source changes on users. That's not ideal either - in fact it's worse, as as it's potentially an ongoing issue. > Oliver > > >>> Oliver >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
