Am 10.08.2012 14:12, schrieb Tom Weissinger:
Oliver,
Thanks for the information.
Is the expectation that commons-configuration will undergo the same sort of
change, where all the package names change to have "configuration2" like
what was done with "lang3"?
Yes, both the package names and the Maven coordinates will change. In
our opinion this is the only way to avoid jar hell.
Oliver
Tom
On Wed, Aug 8, 2012 at 3:38 PM, Oliver Heger
<[email protected]>wrote:
Hi Tom,
Am 07.08.2012 22:21, schrieb Tom Weissinger:
Hi,
What is the timeline for commons-configuration to be compatible with
commons-lang 3.1? We want to be able to use some of the new features of
commons-lang (like generic support) but commons-configuration still uses
the old commons-lang.
The end result is, if we use the latest versions of both libraries, we end
up pulling into 2 different versions of commons-lang JAR. I don't see
this
as a big deal, but if that in itself is an issue, please let me know.
My primary question though is, when will commons-configuration support
commons-lang 3.1? What is holding it back? Just people to work on it?
Thanks!
Tom
the main problem with support for commons-lang 3.x in
commons-configuration is that classes from commons-lang are part of the
public API of commons-configuration. Our release policy demands that a
change in the public API requires a major release - minor releases have to
be binary compatible.
Our original plan was to do some major API cleanup and redesign for the
next Configuration major release. But this will probably take too long.
Therefore, my intension is to release Configuration 1.9 (the current trunk
version which still depends on commons-lang 2.6) in the next few weeks, and
then prepare a major release with support for the most recent lang version
and some minor cleanup only. I hope that this will take place in the nearer
future, but cannot present a concrete time schedule.
In the meanwhile: It is no problem for the two versions of commons-lang to
co-exist. This scenario had been anticipated, and therefore it was ensured
that there are no conflicts.
Oliver
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
user-unsubscribe@commons.**apache.org<[email protected]>
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
