Added a comment to explain splitting will have more impacts and BOM does not even solve it inline.
But stepping back the only issue compress has today is [io] and a bit [codec]. Most of the needed dependencies can be restore in [compress] - keep in mind before the dependency code was hosted in [compress] and everyone was happy. It will also avoid a design pitfall [compress] got since, it integrates with some 3rd parties but not genericly so it would be saner to define a real API for these integration (unwrapping etc) rather than integrating with some other commons and forgetting about all other wrappers we'll encounter. So my plan would be for: 1. revert to drop the optional and additional dependencies (or keep it really optional for the (de)compresser algorithm really needing it but typically tar/tar.gz/zip shouldn't need any 3rd party for ex) 2. check how to integrate with custom io (including [io]) types properly 3. use java-templating plugin or a properties to explicitly list the dependency to add when a dependency is missing and required for advanced algo (7z, pack200 out of my head). Le jeu. 29 févr. 2024 à 13:29, sebb <seb...@gmail.com> a écrit : > On Thu, 29 Feb 2024 at 09:53, Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > > Hi sebb, > > > > On Thu, 29 Feb 2024 at 10:25, sebb <seb...@gmail.com> wrote: > > > > but dependency management can be used to > > > > prevent version mismatches. > > > > > > What dependency management is that? Does Maven manage this? > > > Seems like users would be forced to use extra controls to ensure only > > > comaptible combinations of artifacts were used. > > > > Maven users would be forced to add a new `commons-compress-bom` > > artifact (in my PR) to their dependency management. As far as I know > > other build systems (Gradle, Coursier, probably Apache Ivy) resolve > > version conflicts with a "highest version wins strategy", so the > > change will be a no-op for them. > > Are you sure about that? > What if a component specifies a version range? > It is a bit worse, the transitivity will be broken since often [io] or [codec] are used for other needs and [compress] requires some version. BOM are just working in a single case: when you have a single BOM in the full project or they don't overlap...almost no way it works for commons. > > > Yes, this change might require a developer to supervise the upgrade, > > so it might require a major version bump to drive their attention. > > However personally I find it less problematic than having half the > > dependency stack using `o.a.c.compress` and half of it using > > `o.a.c.compress2`. > > Agreed that might be harder to change automatically. > But my solution in this case would be a complete package/Maven coord break. > > A one-off global edit, but no worries about missing dependency > restrictions. > > > The necessity to align the versions of a multi-module project is > > something many users are aware of (and the others use Spring Boot > > dependency management ;-) ). > > Or they expect Maven to take care of version management for them. > > > Piotr > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
