Another reenginering point I'd like to share with you:
We're currently quite extensively using
org.apache.commons.collections.ExtendedProperties. The main extra
feature vs. java.util.Properties is the handling of multi-values keys.
We removed the runtime-dependency towards commons-collections by using
shading (aka integrating ExtendedProperties class file in our jar).
So far, so good.
But commons-collections 4.0 removed ExtendedProperties, replaced by
org.apache.commons.configuration.PropertiesConfiguration.
Either way, I think we can keep the compile-time dependancy towards
commons-collections-3 for B.C. The class collections.ExtendedProperties
will still be there, shaded, but only used by deprecated methods/classes.
We shouldn't keep non-deprecated dependencies towards
commons-collections-3, and the dilemma is about the replacement of
ExtendedProperties in the new methods and classes. Two options here:
1) use a shaded dependency towards
commons.configuration.PropertiesConfiguration
2) host a clone of ExtendedProperties, as
org.apache.velocity.utils.ExtProperties
Seen from a place far off, option 1 looks like the most natural, but:
- PropertiesConfiguration adds a whole bunch of features we don't
really care about
- PropertiesConfiguration belongs to a whole class hierarchy, whereas
ExtendedProperties is completely standalone
- integrating PropertiesConfiguration will need more reenginering
(constructors aren't the same) and will potentially raise more
backward-compatibility problems
- ExtendedProperties is stable and unlikely to need any future change
So I'm strongly inclined to implement option 2.
For reference, PropertiesConfiguration javadoc:
https://commons.apache.org/proper/commons-configuration/apidocs/org/apache/commons/configuration2/PropertiesConfiguration.html
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
