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