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? > Not sure how to deal with this issue in general. Once the API dependency on Lang is removed, it won't be an issue. > Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
