You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Oliver Heger <ol...@oliver-heger.de> on 2011/08/13 20:53:08 UTC
[configuration] Steps towards next release
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.
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.
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?
And oh yes, I have to scan the release instructions and hope to be able
to do the whole maven magic...
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] Steps towards next release
Posted by sebb <se...@gmail.com>.
Probably because the RC tag was not copied following the release vote.
On 13 August 2011 22:30, Ralph Goers <ra...@dslextreme.com> wrote:
> Why is there no tag in svn for commons-parent version 21?
>
> On Aug 13, 2011, at 11:53 AM, Oliver Heger wrote:
>
>> 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.
>>
>> 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.
>>
>> 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?
>>
>> And oh yes, I have to scan the release instructions and hope to be able to do the whole maven magic...
>>
>> Oliver
>>
>> ---------------------------------------------------------------------
>> 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
Re: [configuration] Steps towards next release
Posted by Ralph Goers <ra...@dslextreme.com>.
Why is there no tag in svn for commons-parent version 21?
On Aug 13, 2011, at 11:53 AM, Oliver Heger wrote:
> 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.
>
> 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.
>
> 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?
>
> And oh yes, I have to scan the release instructions and hope to be able to do the whole maven magic...
>
> Oliver
>
> ---------------------------------------------------------------------
> 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
Re: [configuration] Steps towards next release
Posted by Ralph Goers <ra...@dslextreme.com>.
On Aug 14, 2011, at 2:28 PM, Emmanuel Bourg wrote:
> 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 ?
We have a long way to go for that branch. That said, I'd really like to do that. With some of the refactoring we have talked about I doubt it is going to be binary compatible in its behavior.
>
>
>> 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.
>
>
>> 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.
I would not recommend that. I have people using Commons Configuration on JBoss 5+ and it doesn't work unless they are using VFSFileChangedReloadingStrategy. The normal FileChangedReloadingStrategy can't handle the vfsfile protocol JBoss uses.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] Steps towards next release
Posted by Ralph Goers <ra...@dslextreme.com>.
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
Re: [configuration] Steps towards next release
Posted by Oliver Heger <ol...@oliver-heger.de>.
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
Re: [configuration] Steps towards next release
Posted by Ralph Goers <ra...@dslextreme.com>.
On Aug 16, 2011, at 1:16 AM, Emmanuel Bourg wrote:
> Le 15/08/2011 23:02, Ralph Goers a écrit :
>> 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.
>
> I'm a bit dubious about a complete rewrite. In my experience evolutions tend to work better than revolutions.
I didn't say "complete rewrite". There is quite a large amount of code that can be reused.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] Steps towards next release
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 15/08/2011 23:02, Ralph Goers a écrit :
> 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.
I'm a bit dubious about a complete rewrite. In my experience evolutions
tend to work better than revolutions.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] Steps towards next release
Posted by Ralph Goers <ra...@dslextreme.com>.
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 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
[configuration] CONFIGURATION-427 - WAS Steps towards next release
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 17.08.2011 00:04, schrieb Emmanuel Bourg:
> Le 16/08/2011 22:27, Oliver Heger a écrit :
>
>> Aren't we free to decide how to represent data structures in a
>> configuration? I mean, the dot keys used by XMLConfiguration is also
>> just a convention. We could transform a plist file to a XML-friendly
>> structure and store it in a hierarchical configuration. We just have to
>> document how to access list structures. We could then add specialized
>> convenience methods to PListConfiguration for accessing lists in a way
>> more intuitive for plist users. Wouldn't this be an option?
>
> Our plist configurations are already hierarchical. The difference lies
> in the way the lists are stored.
>
> In the XML way a list is typically structured as:
>
> root
> list
> element -> value1
> element -> value2
> element -> value3
>
> In the plist way it's structured as:
>
> root
> list -> [value1, value2, value3]
>
>
> My understanding is that in a plist file a path can't be used more than
> once. So if you explode the structure of a list to put one element per
> node, you have to reverse the operation and regroup sibling nodes into a
> list when the configuration is written. Headache guaranteed for the
> implementer :)
>
Yes, it would certainly mean more effort on implementation side, but it
would also gain some benefits for users. We do transformations for other
configuration implementations, too, e.g. in
HierarchicalINIConfiguration. Well, the transformation for plist
configurations seems to be more complex.
That said, I am not against the patch. If you think it works for most of
the users, just go ahead and commit it. Alternatively we could postpone
this issue to the next release, so there is more time to think about a
solution. I am still on the opinion that it makes sense to get out a
binary compatible release soon which has been updated for Java 1.5. Here
the fix could be included.
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
Re: [configuration] Steps towards next release
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 16/08/2011 22:27, Oliver Heger a écrit :
> Aren't we free to decide how to represent data structures in a
> configuration? I mean, the dot keys used by XMLConfiguration is also
> just a convention. We could transform a plist file to a XML-friendly
> structure and store it in a hierarchical configuration. We just have to
> document how to access list structures. We could then add specialized
> convenience methods to PListConfiguration for accessing lists in a way
> more intuitive for plist users. Wouldn't this be an option?
Our plist configurations are already hierarchical. The difference lies
in the way the lists are stored.
In the XML way a list is typically structured as:
root
list
element -> value1
element -> value2
element -> value3
In the plist way it's structured as:
root
list -> [value1, value2, value3]
My understanding is that in a plist file a path can't be used more than
once. So if you explode the structure of a list to put one element per
node, you have to reverse the operation and regroup sibling nodes into a
list when the configuration is written. Headache guaranteed for the
implementer :)
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] Steps towards next release
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 16.08.2011 10:06, schrieb Emmanuel Bourg:
> Le 15/08/2011 21:39, Oliver Heger a écrit :
>
>> 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.
>
> We can explore how far we can go on the Java 5 path while maintaining
> compatibility. Not sure it'll be a huge benefit though, I don't think
> it'll change the usability of the API dramatically.
>
>
>> 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?
>
> I don't know for the queries. I admit that's not something I use or
> need, and I suspect people using Commons Configuration to read plist
> files aren't really interested by this feature.
>
> There is a fundamental mismatch in the list structures and I'm not sure
> it can be solved. In the XML case lists are stored as adjacent nodes of
> equivalent names. In the plist case a single node must hold all the
> elements.
I am not familiar with the plist format, so I cannot give a qualified
statement. Just some ideas:
Aren't we free to decide how to represent data structures in a
configuration? I mean, the dot keys used by XMLConfiguration is also
just a convention. We could transform a plist file to a XML-friendly
structure and store it in a hierarchical configuration. We just have to
document how to access list structures. We could then add specialized
convenience methods to PListConfiguration for accessing lists in a way
more intuitive for plist users. Wouldn't this be an option?
Oliver
>
>
>> 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.
>
> Agree on that
>
>
> 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
Re: [configuration] Steps towards next release
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 15/08/2011 21:39, Oliver Heger a écrit :
> 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.
We can explore how far we can go on the Java 5 path while maintaining
compatibility. Not sure it'll be a huge benefit though, I don't think
it'll change the usability of the API dramatically.
> 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?
I don't know for the queries. I admit that's not something I use or
need, and I suspect people using Commons Configuration to read plist
files aren't really interested by this feature.
There is a fundamental mismatch in the list structures and I'm not sure
it can be solved. In the XML case lists are stored as adjacent nodes of
equivalent names. In the plist case a single node must hold all the
elements.
> 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.
Agree on that
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] Steps towards next release
Posted by "ralph.goers @dslextreme.com" <ra...@dslextreme.com>.
http://wiki.apache.org/commons/CreatingReleases for most of the information
as I am using the maven release plugin. But I'm also referring to
http://commons.apache.org/releases/index.html to try to make sure nothing is
missed. This process has been a bit painful for me as most commons projects
aren't multi-projects and it is my first time as acting as a release manager
at the ASF.
Ralph
On Tue, Aug 16, 2011 at 1:28 PM, Oliver Heger
<ol...@oliver-heger.de>wrote:
> Am 16.08.2011 10:40, schrieb Ralph Goers:
>
>
>> On Aug 15, 2011, at 12:39 PM, Oliver Heger wrote:
>>
>> 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.
>>>
>>
>> As you've probably noticed I've been working on this and hope to get it
>> locked down in a day or two.
>>
>
> That's great, Ralph!
>
> BTW, which release instructions do you follow? I will have to do the same
> dance...
>
> Oliver
>
>
>> Ralph
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [configuration] Steps towards next release
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 16.08.2011 10:40, schrieb Ralph Goers:
>
> On Aug 15, 2011, at 12:39 PM, Oliver Heger wrote:
>
>>> 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.
>
> As you've probably noticed I've been working on this and hope to get it locked down in a day or two.
That's great, Ralph!
BTW, which release instructions do you follow? I will have to do the
same dance...
Oliver
>
> Ralph
> ---------------------------------------------------------------------
> 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
Re: [configuration] Steps towards next release
Posted by Ralph Goers <ra...@dslextreme.com>.
On Aug 15, 2011, at 12:39 PM, Oliver Heger wrote:
>> 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.
As you've probably noticed I've been working on this and hope to get it locked down in a day or two.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] Steps towards next release
Posted by Oliver Heger <ol...@oliver-heger.de>.
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
Re: [configuration] Steps towards next release
Posted by Emmanuel Bourg <eb...@apache.org>.
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 ?
> 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.
> 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.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] Steps towards next release
Posted by Ralph Goers <ra...@dslextreme.com>.
I was waiting for v 2.2 of the release plugin. It was released several weeks ago.
As it happens I tried to do the release of vfs again last night and it failed due to changes in the commons parent pom or one of its parents. It doesn't appear to support multi module projects as the maven-bundle plugin is smart enough to not generate an OSGi manifest for the parent (pom) project but then the jar plugin fails due to no OSGi manifest being present. I haven't looked at the parent poms yet, but I have no idea why this error only occurs during a release as I would think that SNAPSHOT jars should have the OSGi stuff too.
In any case, I am debugging this right now. and will try to get the release done this weekend.
I'm not in favor of separating out the vfs stuff unless getting the release cut continues to fail.
Ralph
On Aug 13, 2011, at 11:53 AM, Oliver Heger wrote:
> 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.
>
> 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.
>
> 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?
>
> And oh yes, I have to scan the release instructions and hope to be able to do the whole maven magic...
>
> Oliver
>
> ---------------------------------------------------------------------
> 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