gharris1727 commented on PR #14092: URL: https://github.com/apache/kafka/pull/14092#issuecomment-1652125644
> Can you explain better what you mean here? By "version mixing" I mean that artifacts from two different versions from different versions are present on the classpath at the same time. The "long-range" just means that the distance between the versions is very large, in this case between all previous versions (including 0.8.x) and trunk. When we mix artifacts of different versions, there's a "compatibility boundary" that separates them. Imports across this compatibility boundary are not guaranteed, because the code was not compiled together. There are places where we expect a compatibility boundary, and we commit to those in the public documentation. But when we put a compatibility boundary in an atypical place (between the tools jar and clients, or clients and the rest of AK) then otherwise reasonable changes to internal classes can break the build. I said that I thought the boundary was already in the least impactful place, because there is so little code in the tools jar, and so very little opportunity for imports across the compatibility boundary to break the system tests. The clients artifact is much larger and has much more active development, and I think it is at more risk of breaking these tests. So then, I think the best solutions to this problem are going to eliminate the cross-version artifact mixing, or if that isn't possible, reduce the range of versions that are mixed to allow the dev branch to move forward. In #13313 I explored eliminating the artifact mixing, but it turned out that the 0.8.x tools was missing functionality, and so I had to inject the 0.9.x tools jar. I think we can do something similar here, try to remove the artifact mixing, and if that fails, find an intermediate version that can be injected instead of trunk. @fvaleri Let me know if that is more clear, I'm eager to help get the fix merged, so thank you for working on it! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org