Hi all, I have spent a lot of time over the last week to address most of the most pressing dependency problems we were having. I noticed that we had some pretty dangerous mixtures in some of our libraries. Such mixtures can produce pretty hard to diagnose problems.
https://github.com/apache/iotdb/pull/11150 So, I have turned on the enforcer plugin and increased the severity of many plugins: * The dependency plugin now fails the build: * if you use a transitive dependency and not declaring it as an import * if you have a compile dependency, that should be a test-dependency * if you have dependencies that are not used * The enforcer plugin now fails the build, if we have multiple versions of transitive dependencies in the dependency tree of an artifact * The enforcer plugin now fails the build, if we are using dependencies for which CVEs have been reported * The enforcer plugin now fails the build, if multiple dependencies provide classes with the same name, but different content (Usually shaded or no-deps dependencies) So, I have: * updated the dependencies of all project to import what is needed and to import it into the correct classpath. * managed the dependencies of conflicting transitive dependencies to pull in a clearly defined version. * gone through dependencies for which vulnerabilities were reported and updated almost all to safe versions. * removed most of the “with-deps” dependencies and replaced them by cleanly defined imports. * I refactored code blocks, where we had unfortunate imports (Base64 decoder that pulled in Glassfisch, Test that pulled in Tomcat) The PR is still not mergeable, because I also have a PR running in Ratis, which we need for running my version. But I was told that a new version will be made available soon. I also updated the poms so all inner-project dependencies have the full version-string “0.13.0-SNAPHOT” instead of “${project.version}” as it doesn’t add more work when releasing, and this way you can instantly see the version of a pom without having to scroll up. This has saved my life in other projects way too often. All third-party dependencies are managed and don’t provide the version in the pom where they are used. All versions are defined in the parent pom. As finding dependencies some-times is a challenge because the order of declaration varies from module to module, I used a plugin to sort the elements of the poms in a unified way. So, dependencies are sorted by “scope”, “groupId”, “artifactId” … this makes finding a dependency a lot easier. I know the order of dependencies matters, but as we’re explicitly managing all important dependencies, the order doesn’t matter. Regarding the CVEs, I couldn’t eliminate all CVEs as for some new ones there simply are no fixed versions yet. In these cases, I explicitly excluded them and added a todo to keep track of them. Some CVEs simply don’t effect us. If a CVE is reported to have an effect on a component that we are not using, I also excluded these versions and added a comment above, describing why I excluded it. I really hope I can finish this task asap as it was extremely difficult and took way too much time. But I think the project is in a way better and safer state with these changes. Chris
