Hi.
Le lun. 28 oct. 2024 à 13:38, Emmanuel Bourg <ebo...@apache.org> a écrit :
>
> Le 26/10/2024 à 20:32, Elliotte Rusty Harold a écrit :
>
> > That's exactly backwards. Code changes have to be technically
> > justified. The responsibility is on the proposer, not the vetoer, to
> > demonstrate that the change os worthwhile. Code changes are not
> > accepted by default unless there's good and valid reason for them. If
> > you can't get even one committer to +1 a PR thgen it doesn't meet the
> > threshold for merging.
>
> It goes both ways, you can't veto without a good reason either. "I don't
> like it" is definitely not one.
>
> It looks like I have to explain in more details the change, so here it is:
>
> When I implemented the plist configuration in 2005 [1] I needed a Base64
> and an hex encoder/decoder. Base64 isn't exactly trivial to implement
> and Commons Codec already has one, so I imported the dependency.
>
> The inflation of dependencies was seen as a concern, the plist
> configuration initially used Commons Digester which was eventually
> replaced by pure SAX code in 2007 [2], Commons Collections was also used
> and got removed in 2014 [3]. Some dependencies were made optional to
> reduce the amount of dependencies pulled [4], but this made an awkward
> user experience where unsuspecting users would get a
> ClassNotFoundException when trying to use the plist configurations.
>
> Java 8 was released in 2014 with a long awaited Base64 implementation,
> and Commons Configuration moved to Java 8 in 2018. I've updated the code
> last week to use java.util.Base64 instead of Commons Codec [5].
Up to here, I don't think that anyone would dispute that it is an
overall improvement (more code reuse, less maintenance).
> At this
> point Commons Codec was only retained for encoding/decoding hexadecimal
> values. Commons Codec weighs 360KB and must be added manually to the
> classpath, encoding/decoding hexadecimal is trivially handled by ~20
> lines of code, so dropping the dependency was the obvious choice to me
> and in the spirit of the previous dependency removals.
The last part involves the trade-off between "code reuse" and "dependency".
20 lines is small, sure, but every "bloat" has always started small; then the
same argument applied for every new small bit of code: Not worth adding a
dependency).
So this circles back to the proposal in the thread with "Subject:"
Usage of (Commons) dependencies
That is: _If_ we had a ("very low-level") module that provides the 20 lines
needed by [Configuration] and [Lang], they could both depend on it, with
almost no overhead or additional risks: No undue dependency (Emmanuel's
point), potential fixes would be implemented once (Gary's point).
We could then "manage" this via JIRA:
1. Open a report stating the need for the "very low-level" module and its
scope (i.e. the list of features, such as the "20 lines" referred to here).
2. Open a JIRA sub-task: Replace the "20 lines" once the module is
released.
3. Add a comment around the "20 lines" with a reference to the sub-task.
How does that sound?
Regards,
Gilles
>
> Emmanuel Bourg
>
> [1]
> https://github.com/apache/commons-configuration/commit/02f66818#diff-a8d5e2a5cbeb500e59aca88e0613283c57d530c6df7630555d5a08bc5c3a660fR258
> [2] https://github.com/apache/commons-configuration/commit/8b26e6e6
> [3] https://github.com/apache/commons-configuration/commit/25490ca9
> [4] https://github.com/apache/commons-configuration/commit/63776cc0
> [5] https://github.com/apache/commons-configuration/commit/7b434dbd
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
