Vladimir, First, I demonstrated to you already how this works for transitive dependencies.
Next, I told you many times: Maven is not the tool that overrides user input [1] and [2]. You should do your homework. Somehow, I have a feeling that all that you ask boils down to automatically accepting (machine or similar generated; think dependabot) PRs, where "bump property from version X to Y" is assumed to "it does the job of updating a dependency". As I have shown to you, it may work for transitive dependencies, but will never for direct dependencies, where you have both, X and Y enlisted as direct ones (exactly as in your updated example). [1] https://github.com/vlsi/jarsplit/blob/b7dae3f1609b978e1a33ffa63d717bc66e45daa5/app-gradle/build.gradle.kts#L9-L12 [2] https://github.com/vlsi/jarsplit/blob/b7dae3f1609b978e1a33ffa63d717bc66e45daa5/app-maven4/pom.xml#L8-L19 On Tue, Nov 4, 2025 at 10:19 PM Tamás Cservenák <[email protected]> wrote: > > Just a bit of clarification, as Vladimir is a bit bending things: > > Guava devs said this: > "This might have made sense to do in the original release. (And I have > to imagine that we didn't even think of the CVE angle at that point.) > After that point, though, it became a recipe for conflicts between > some version of the main guava artifact and some other version of a > package like guava-base. We could reconsider someday if the ecosystem > were to have better support for splitting up artifacts in the future. > > Another part of our story has been that most users' needs don't follow > clean package lines. Maybe they want just an implementation of BiMap, > but they still get all of collect (and its dependencies (annotations, > base, math, primitives). People who want to optimize for binary size > are going to get better results from custom shading/minimization. > > Historically, we also worried that Maven users would end up with, say, > guava-base:10.0.0 but guava-collect:20.0.0, and then they'd have > problems because collect depends on base features that we added later. > This is of course a much more general problem that is best solved with > Dependabot / requireUpperBoundDeps / Gradle / whatever, but it was > particularly acute back when Guava was adding features rapidly and the > ecosystem was less developed in how it handled dependency hygiene. > (Also, as everyone knows, Guava was also removing APIs, creating > potential trouble in the other direction.) Oh, and it used to be that > more people were manually downloading jars, too! So extra jars > actually increased friction. [edit: We've also considered that we > might someday want to allow circular dependencies between packages, > but I'm not convinced that will ever happen.] Anyway, those concerns > are all gone or at least reduce nowadays. > > (Compare also the complaints we've gotten about our listenablefuture > and failureaccess jars, which normally "just worked" but have which > ended up causing significant trouble in some cases. Those are of > course not the specific kind of change you're suggesting here; I just > offer them as examples of how any extra bit of complexity in our build > setup will end up causing problems, both foreseen and unforeseen.) > > There are some past discussions of this that I (or someone else) might > manage to dig up later, but I think that's the short answer: It was > arguably the right decision years ago, but at this point, any change > to our dependency structure seems likely to create more problems than > it solves." > > Then Vladimir wrote this: > "Do you mean the key culprit is Maven’s inability to deal with old > guava:20 and new guava-hash:42 being present both in the dependency > tree?" > > Which was confirmed by Guava devs by "Right". > > But there is much more to it, as Guava devs added a great deal of > explanation of other aspects too (and history bits). > > Just saying, to have this on the list too, for "those who find it in > the search". > > Thanks > T > > On Tue, Nov 4, 2025 at 9:45 PM Vladimir Sitnikov > <[email protected]> wrote: > > > > Here's one more data point. > > > > Guava developers say "Maven's inability to deal with old guava:20 and new > > guava-hash:42 being present both in the dependency tree" is > > a showstopper for splitting Guava into several modules. End-users requested > > the split multiple times for the past decade. > > > > See https://github.com/google/guava/issues/8079#issuecomment-3487896211 > > > > So the issue is real. Maven could do much better. > > > > Vladimir --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
