Le 28/10/2024 à 14:30, Gilles Sadowski a écrit :
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?
If commons-configuration was depending on commons-codec-hex I don't think I would have removed the dependency before the switch to Java 17.
But is it a good idea to create such an artifact now, just for the needs of commons-configuration, obsolete for any other usage, and that will be replaced by Java 17 HexFormat within 2 or 3 years? I don't think so. I'm not opposed to the idea but it would be weird in my opinion. I'd rather shade the commons-codec Hex class.
Emmanuel Bourg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
