[configuration] Release 1.2

[Oliver Heger <ol...@t-online.de>]

A while ago we discussed the possibility of a new release of 
commons-configuration. Now back from my vacations I could spend some 
time on this task.

Following is a Todo list with things I would like to get done before a 
release. So this can be considered as a simple release plan. Feel free 
to comment or add further points.

- Bugzilla:
There are three tickets in the "need info" state, which can be closed 
because of lack of feedback. For 35858 we can decide whether the 
subset() implementation of HierarchicalConfiguration can be dropped. For 
other tickets I feel no urgent need to address any before the release.

- Ensure binary compatibility
A Clirr or JDiff report should be created as mentioned in the "Releasing 
Components" section.

- Documentation
Some improvements of our user guide won't be wrong.

- Code quality
Address errors and warnings displayed by Checkstyle, Javadoc, and other 
reports. Maybe try to further increase test coverage.
Apropos: What's the state of the new plist package? Test coverage is 
quite low (maybe because a failing unit test was disabled), and the 
Eclipse compiler outputs several warnings (e.g. about unused variables). 
Is it yet mature?

Any other points?

Oliver

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

Re: [configuration] Release 1.2

[Oliver Heger <ol...@t-online.de>]

Emmanuel Bourg wrote:

> Oliver Heger wrote:
>
>> - Bugzilla:
>> There are three tickets in the "need info" state, which can be closed 
>> because of lack of feedback. For 35858 we can decide whether the 
>> subset() implementation of HierarchicalConfiguration can be dropped. 
>
>
> It can't be removed right now due to an assertion that fails without 
> this specific implementation. I suggest to keep the method as is for 
> the next release and try to remove it for the 1.3 release.

Hm, I see. Depending on the way the subset is constructed the key passed 
in for the test is either interpreted as 
"(tables.table.fields.field.name)(0)" or as 
"tables.table.fields.field.(name(0))"; these expressions have different 
results. Okay, let's differ that to the 1.3 release.

[...]

>
> There are two issues left that are related to hierarchical 
> configurations in general, fixing these issues could also improve the 
> test coverage:
>
> 1) adding a List, or adding more than once a value with the same key 
> generates several nodes instead of a node with a List value.
>
> For example, with:
>
> config.addProperty("array", "1");
> config.addProperty("array", "2");
>
> The property list will look like this:
>
> {
>     array = 1;
>     array = 2;
> }
>
> instead of:
>
> {
>     array = (1, 2);
> }
>
> same thing with the xml variant:
>
> <plist>
>   <dict>
>     <key>array</key>
>     <string>1</string>
>
>     <key>array</key>
>     <string>2</string>
>   </dict>
> </plist>
>
> instead of:
>
> <plist>
>   <dict>
>     <key>array</key>
>     <array>
>       <string>1</string>
>       <string>2</string>
>     </array>
>   </dict>
> </plist>

Maybe a HierarchicalConfiguration could be made configurable to support 
both models for adding properties (always creating new nodes versus 
using existing ones). We could also define something like an 
AddPropertyStrategy, but this seems to be a bit of an overkill. In any 
case AFICT methods affected by this change would be addPropertyDirect() 
and getProperty().

What would be the semantics for indices? ATM indices are evaluated on a 
per node basis. So e.g. if a node has three values, it will be counted 
as 1, not as 3. Is this okay for acessing property values? Changes this 
could have a major impact I fear.

Oliver
[...]

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

Re: [configuration] Release 1.2

[Emmanuel Bourg <eb...@apache.org>]

Oliver Heger wrote:
> A while ago we discussed the possibility of a new release of 
> commons-configuration. Now back from my vacations I could spend some 
> time on this task.

Thank you for taking care of this task.

> - Bugzilla:
> There are three tickets in the "need info" state, which can be closed 
> because of lack of feedback. For 35858 we can decide whether the 
> subset() implementation of HierarchicalConfiguration can be dropped. 

It can't be removed right now due to an assertion that fails without 
this specific implementation. I suggest to keep the method as is for the 
next release and try to remove it for the 1.3 release.

> For 
> other tickets I feel no urgent need to address any before the release.

There is one last issue I'd like to address before the 1.2 release, 
that's the instance specific delimiter (Bug 35828), but I haven't got 
much feedback on this topic.


> - Documentation
> Some improvements of our user guide won't be wrong.

I agree, I updated the dependency page recently, the overview could be 
improved with some examples detailing the new property list configurations.


> - Code quality
> Address errors and warnings displayed by Checkstyle, Javadoc, and other 
> reports. Maybe try to further increase test coverage.
> Apropos: What's the state of the new plist package? Test coverage is 
> quite low (maybe because a failing unit test was disabled), and the 
> Eclipse compiler outputs several warnings (e.g. about unused variables). 
> Is it yet mature?

I ran Clover yesterday and the coverage was indeed low on the plist 
package (37%). I fixed the disabled tests and added some more. I also 
removed unused code from the classes generated by JavaCC, but this 
effort will be lost if we have to regenerate the classes to fix a parser 
issue. At this point the coverage is around 62%.

There are two issues left that are related to hierarchical 
configurations in general, fixing these issues could also improve the 
test coverage:

1) adding a List, or adding more than once a value with the same key 
generates several nodes instead of a node with a List value.

For example, with:

config.addProperty("array", "1");
config.addProperty("array", "2");

The property list will look like this:

{
     array = 1;
     array = 2;
}

instead of:

{
     array = (1, 2);
}

same thing with the xml variant:

<plist>
   <dict>
     <key>array</key>
     <string>1</string>

     <key>array</key>
     <string>2</string>
   </dict>
</plist>

instead of:

<plist>
   <dict>
     <key>array</key>
     <array>
       <string>1</string>
       <string>2</string>
     </array>
   </dict>
</plist>


2) a map or a configuration added to a hierarchical configuration should 
probably be transformed into a tree of nodes.

For example:

Map map = new HashMap();
map.put("foo", "1");
map.put("bar", "2");

config.addProperty("key", map);

This would produce a "key" node with two "foo" and "bar" children, 
instead of a "key" node with a Map value. Both forms are represented by 
the same plist file, but they are not equivalent.

Emmanuel Bourg








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