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 and may be less straight-forward from a user's point of
view.
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
