I am aware of two resolution strategies: use the most recent of the conflicting versions; present the user with an error message in the event of a conflict. However, neither of these are suitable for my use case. I would like to be able to specify ‘yes, I know there are conflicting versions and I want to use both’.
I appreciate that this might not make any sense for certain types of artifact (e.g. Jars) for which an application can only really use one version, but my use case is:
a multi-project environment * some projects depend on different versions of the same artifact * the artifact in question could be a zip file containing header files and static libraries * the artifact in question could be a DLL which does behave nicely when loaded into an application which uses other versions of that DLL
Any suggestions as to how I can achieve this kind of resolution strategy, either on a per dependency basis or globally?
At the moment, there’s no ‘do nothing’ conflict resolution strategy. I don’t think this kind of strategy is a best fit to solve the use case. There might be some jar that you expect and want multiple different versions on the classpath. However, many other jars may fail badly at runtime if multiple versions are included. So to fix this use case I would rather configure it explicitly for the dependency that requires it.
If you tell us a little bit more about the exact use case we may be able to provide a workaround.
Sure, here are some more details about my use case. We have a large multi-module development environment, which consists of static libraries, DLLs and EXEs. It’s completely fine for different DLLs or EXEs to use different versions of that static library. There is no concern about run-time compatibility - it will simply work.
Yes, all modules should ideally use the latest and greatest version (and avoid dependency conflicts) but that’s not feasible. The teams have different testing and release schedules so we end up with DLLs using different versions of the static library.
The static library (and the necessary header files) is zipped up and stored in an Ivy repository. I’ve written a Gradle plugin which unpacks that zip file to the workspace. This copes with different versions of the same module because I can include the version number in the path e.g.
At the moment the only workaround I’ve got is to create additional configurations so that Gradle doesn’t detect the conflicting versions. As long as I iterate over all configurations, this allows me to unpack the dependencies to the workspace but it messes up the meta-data when it comes time to publish artifacts for the DLLs or the application. I don’t have a solution for that yet.
I’m aware of GRADLE-646 which would probably help my use case, as long as it was possible for a custom version resolution strategy to return multiple versions, rather than being forced to only return one version.
I’m open to other solutions, including forking Gradle and hacking it to ignore conflicts.