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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
