dependenciesToScan helps some, but different use case in my eyes. The intended use is to share a test suite between multiple implementors. For instance a TCK. As an example, a JPA TCK could provide a test artifact that the Hibernate team use dependenciesToScan in their test setup to include into their build.
As a user, I'm not interested in the JPA TCK, I have my own tests I want to test against multiple implementations, Hibernate and EclipeLink (that's where this come in).
Perhaps a good way to look at it would be;
- I want my code to comply with a given test suite (dependenciesToScan)
- I want my code to run on multiple implementations (additionalProfiles)
I could create a common test suite in my project and create multiple test modules with individual dependency sets and import the test suite using dependenciesToScan, but that doesn't solve the multiple modules issue..
classpathDependencyExcludes works the opposite direction, you would have to include all test-runtime dependencies in test scope and exclude the ones you don't want in the surefire execution. e.g. runtime-a, runtime-b and runtime-c are test scoped, then in execution of runtime-a you need to exclude runtime-b and runtime-c. With only 3 dependencies that's not too hard, but confusing. Now if runtime-a has runtime-a-N dependencies in a group you're in trouble. Not to mention of course that when runtime-a|z are resolved on the same classpath maven will do dependency conflict resolution, meaning depending on just runtime-a might not resolve the same as depending on runtime-a and runtime-b at the same time. So in short, no