I'm fine with cloning it. Why bring in all the other stuff when we just need a simple feature.
On Jul 17, 2016 11:27 AM, "Claude Brisson" <cla...@renegat.net> wrote: > 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 > >
