I worked on the PR and solved the version conflicts now. I considered removing the plugin, as you proposed, but I ended up using it instead, because its functionality is still useful in my opinion. 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. But I still prefer it this way instead of the way Gradle resolves conflicts.
Some of the repetitiveness in the dependencies.gradle for resolving conflicts could be simplified by just iterating over the libraries of the catalog and adding them all as constraints. But I felt like doing so could have unexpected resolutions, so I went for the repetitiveness. > I've toyed with gradle's notion of platforms but they never worked the way I wanted them to. 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). But that seems to be only relevant if the users integrate individual Solr modules into other projects, and it doesn't look to me like Solr is that kind of project (correct me if I'm wrong). I also thought that applying a BOM from another project as a constraint would resolve at least some of the conflicts, but I think that is not the case. I am now planning to improve the documentation for the dependencies, especially the licensing part. It is quite time consuming and difficult if you don't know where to search for the license and notice files. In the other thread about Resolving dependencies with depdencychecks plugin <https://lists.apache.org/thread/mhvcfxy6dh2x1zqbxvrnjqch47222rjl> 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. Since the tests are supposed to ensure the stability of the project with the libraries selected, I went for a group where both main and test configurations (from your example) are included, so that when executing tests, the same library versions are used as in the final build artifact. I don't know if this way of thinking is actually correct, so any thoughts on that would be very helpful. Best, Christos >
