> There isn't a singular "classpath" > (DependencySet? in Gradle). I think there are multiple "classpaths" > for many things (e.g. compiling main sourceSet vs compiling test > sourceSet) for each module (many modules).
These configurations are from the java plugin in gradle and most of them are tied together because of inheritance between configurations. But in general - no - configurations can have any dependencies you wish (and they are resolved within a configuration and its network of inherited configurations and constraints). There is flexibility and beauty in it - much like with different class loaders having different set of jars. But it does get complicated when you're trying to ensure consistency across different independent configurations. Different artifact resolution from the same initial conditions (dependency version and constraints) is easier to show for two different subprojects - it is typically enough to have a transitive dependency at a different minor version in one of them to resolve differently. Gradle has its own recommendations on how you can solve this but they're beyond my understanding (especially when they don't work as advertised...). > But every classpath > produced by Gradle (DependencySet) should have one version of a given > dependency (group+artifactId). > Eh... It's a longer story... It's always a configuration resolution - there is no global set of dependencies. Even palantir's plugin doesn't guarantee consistent resolution, actually. That's why that plugin of mine is useful - it picks the final artifacts and verifies they use unique version number across the set of configurations you desire. Dawid
