> What palantir-consistent-versions did (always taking the ceiling) is easier but less transparent, I am for transparency too, I had enough troubleshooting sessions for fixing something that I couldn't see.
What I also found is that there are some difficulties in keeping the constraints clean the way we plan to resolve the reported conflicts. Once a constraint is added, another constraint may resolve as well, but you only know of its redundancy if you run the gradle task inbetween each constraint addition / removal, or check the dependency insights for each conflict individually. I couldn't find a way to identify redundant constraints either for cleaning up in the long run the constraints. Any ideas how this could be tackled? What would be the drawbacks / risks for allowing multiple versions of the same library in case of transitive dependencies and their resolution? Is that even possible if we lock dependency versions? Christos On Mon, Aug 19, 2024 at 8:17 PM Dawid Weiss <dawid.we...@gmail.com> wrote: > Hi Christos, > > > I am just not very happy with the repetitive constraints and the need to > include transitive dependencies in the version catalog whenever there is a > version mismatch that needs to be synced. > > I share your pain - there is added verbosity here. I haven't found an > elegant way to deal with this. What palantir-consistent-versions did > (always taking the ceiling) is easier but less transparent, in my > opinion. I look forward to seeing something that would be a nice > middle ground. > > > I tried integrating a platform module to understand its use case and > limitations, but it doesn't seem to be very helpful here. I therefore share > your opinion on that. It would be something we could consider if we publish > each Solr module separately and allow the users to sync the versions of > each module with the platform (as a BOM probably). > > I did some prototyping with BOMs and platform modules but it never > worked for me quite right (I played with some intentionally hairy > transitive conflicts). Maybe it's my lack of experience or my lack of > understanding that is to blame here. > > > In the other thread about Resolving dependencies with depdencychecks > plugin and in the Lucene project you went for two configuration groups, one > for main and one for test. I would probably do the same, but when I thought > it through, I was not sure if this is what we want. I assume unexpected > behavior if the main / compile and runtime configurations may use different > versions of libraries than the test compile and test runtime. > > You are correct - the two different configurations (main/test) may > resolve transitives in a different way. My reasoning was that it's an > unlikely event - most of the time the test configuration will inherit > a bulk of deps from the main one, then add test-only libraries. The > overlap in their transitive set should be small or even none. The > benefit of keeping the two separate is to have an "inventory list" in > the lock file - you can clearly see when a new library (or an upgrade) > made it to the main set of dependencies when you're updating the lock > file and running git diff... This said, that plugin of mine is > actually fairly agnostic in terms of the number or arrangement of > configurations which are checked for consistency. So you could have > three separate ones - main, test and main+test... If there is an > inconsistency, it will be signalled and you'll have to correct it via > the constraint mechanism. Again - not sure which way is the best way > (what you did is likely better for consistency). > > Dawid >
