commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [configuration] Steps towards next release
Date Tue, 16 Aug 2011 06:05:52 GMT
That's OK.  At least getting agreement on tackling the interfaces first gives us somewhere
to start. Then we can debate if or where generics, etc. should be used.

The reason I still prefer to base on the Hierarchical is that the current way of hooking in
the File configuration support is just ugly.

Ralph

On Aug 15, 2011, at 10:52 PM, Oliver Heger wrote:

> Am 15.08.2011 23:02, schrieb Ralph Goers:
>> I don't know.  I think it really needs a refactoring.  We always said that all configurations
should be based on HierarchicalConfiguration but that still hasn't happened.  Attribute splitting
and delimiter parsing have been a pain.
>> 
>> I think it would be great to start with clean interfaces and then implement from
that by refactoring or rewriting as necessary.
>> 
>> Ralph
> 
> On the long run there is certainly the need for a refactoring. My worries are that this
will take again some years before the next release version is ready. So maybe it serves our
users better to have an intermediate version which is not that much different from the current
version, but is compatible with Java 1.5 and the newer commons components.
> 
> +1 to the approach of starting with clean interfaces, and the delimiter parsing stuff
is also on top of my list of things to change.
> 
> About the "all configurations are hierarchical" concept I am not sure any more. I fear
that this would slow down access to configuration data (tree-like access vs map access) while
there is not much benefit because more sophisticated queries do not make much sense if the
data lacks structure. But I am open for discussion.
> 
> Oliver
> 
>> 
>> On Aug 15, 2011, at 12:39 PM, Oliver Heger wrote:
>> 
>>> Am 14.08.2011 23:28, schrieb Emmanuel Bourg:
>>>> Le 13/08/2011 20:53, Oliver Heger a écrit :
>>>>> Hi,
>>>>> 
>>>>> as you may have noticed, I have started some work in order to prepare
a
>>>>> release (version 1.7) of [configuration]. I assume this will be the last
>>>>> release compatible with Java 1.4.
>>>> 
>>>> So the release after 1.7 would be the code on the 2.0 branch ?
>>> 
>>> To be honest, I think the branch is a mess.
>>> 
>>> Maybe [configuration] should follow the road other components have gone before:
make the APIs ready for Java 5+, but do only limited refactoring. Ideally, this could even
be done in a binary compatible way. However, I am not sure whether binary compatibility can
be achieved as we might want to polish some interfaces.
>>> 
>>>> 
>>>> 
>>>>> I plan to have a look at the current Jira issues, but I hope there are
>>>>> no major issues open which have to be addressed immediately.
>>>> 
>>>> If possible I'd like to get CONFIGURATION-427 addressed in the 1.7
>>>> release. If it's ok to store a list of values inside a node I suggest
>>>> applying my patch without the new method in ConfigurationNode to
>>>> preserve the binary compatibility.
>>> 
>>> Feel free to commit. But are you sure there are no undesired side effects? I
can imagine that queries won't work as expected if a node contains multiple values. Maybe
some tests can be added in this respect?
>>> 
>>>> 
>>>> 
>>>>> The main open point is still the snapshot dependency to [vfs]. What is
>>>>> the status there? IMHO it is also an option to create a release branch,
>>>>> remove the dependency there, and release 1.7 without [vfs] support. It
>>>>> is no problem to push out another release as soon as [vfs] 2.0 becomes
>>>>> available. WDYT?
>>>> 
>>>> I would release 1.7 without vfs 2.0, we can still release 1.8 later when
>>>> vfs is ready.
>>> 
>>> Probably a question of time. If the vfs 2.0 release is a matter of some days
or weeks, this is no problem. The release preparations for [configuration] will take some
time, too. However, if we were talking about some more months, I would prefer a release without
vfs, too.
>>> 
>>> Oliver
>>> 
>>>> 
>>>> Emmanuel Bourg
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message