./gradlew compilej
> Task :lib:compileJava FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':lib:compileJava'.
> Could not resolve all files for configuration ':lib:compileClasspath'.
> Could not resolve com.edulify:play-hikaricp_2.11:2.0.6.
Required by:
project :lib
> No matching configuration of com.edulify:play-hikaricp_2.11:2.0.6 was found. The consumer was configured to find an API of a library compatible with Java 11, preferably in the form of class files, preferably optimized for standard JVMs, and its dependencies declared externally but:
- Configuration 'compile':
- Other compatible attributes:
- Doesn't say anything about its component category (required a library)
- Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
- Doesn't say anything about its target Java version (required compatibility with Java 11)
- Doesn't say anything about its elements (required them preferably in the form of class files)
- Doesn't say anything about its usage (required an API)
- Configuration 'optional':
- Other compatible attributes:
- Doesn't say anything about its component category (required a library)
- Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
- Doesn't say anything about its target Java version (required compatibility with Java 11)
- Doesn't say anything about its elements (required them preferably in the form of class files)
- Doesn't say anything about its usage (required an API)
- Configuration 'pom':
- Other compatible attributes:
- Doesn't say anything about its component category (required a library)
- Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
- Doesn't say anything about its target Java version (required compatibility with Java 11)
- Doesn't say anything about its elements (required them preferably in the form of class files)
- Doesn't say anything about its usage (required an API)
- Configuration 'provided':
- Other compatible attributes:
- Doesn't say anything about its component category (required a library)
- Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
- Doesn't say anything about its target Java version (required compatibility with Java 11)
- Doesn't say anything about its elements (required them preferably in the form of class files)
- Doesn't say anything about its usage (required an API)
- Configuration 'runtime':
- Other compatible attributes:
- Doesn't say anything about its component category (required a library)
- Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
- Doesn't say anything about its target Java version (required compatibility with Java 11)
- Doesn't say anything about its elements (required them preferably in the form of class files)
- Doesn't say anything about its usage (required an API)
- Configuration 'sources':
- Other compatible attributes:
- Doesn't say anything about its component category (required a library)
- Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
- Doesn't say anything about its target Java version (required compatibility with Java 11)
- Doesn't say anything about its elements (required them preferably in the form of class files)
- Doesn't say anything about its usage (required an API)
- Configuration 'test':
- Other compatible attributes:
- Doesn't say anything about its component category (required a library)
- Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
- Doesn't say anything about its target Java version (required compatibility with Java 11)
- Doesn't say anything about its elements (required them preferably in the form of class files)
- Doesn't say anything about its usage (required an API)
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 1s
1 actionable task: 1 executed
Yes, unfortunately not. I was hoping it would say WHY it could not resolve that dependency. It is difficult to say without knowing the entire configuration of your machine and project.
Browsing their repo, the artifact does seem to exist:
My guess is that something is wrong with your repository setup. Try replacing -i with -d to get debug output, and go through it to see if it shows the URL being used to try to fetch the JAR, then you can verify if that URL is valid or not.
But it says it, right in the first post in this thread.
There are 7 configurations defined in that ivy.xml file.
And Gradle cannot decide which one to use.
ivy.xml files are very flexible regarding the configurations you define and what they might mean.
But this flexibility comes with the price that a consumer maybe cannot decide what to use without further information.
Most Ivy files I have seen so far have a configuration called default, which usually extends master and runtime.
This default configuration is, what is used by Gradle if it is found.
If it is not found, then Gradle has no choice other than asking the user which configuration he wants.
So you need to tell Gradle exactly which configuration you like to have like this:
The closest I had just got was to map the runtime variant to some new added variant, based on the variant model docs page, but I couldn’t make the final logical leap to setting the targetConfiguration.
You can of course also create a variant and let the variant-aware resolution do its work. It doesn’t really matter how you name the variant. The important part is, that you add the proper attributes so that the variant aware resolution can decide which to use. This is for example helpful if you want the compile configuration (with its dependencies) for compilation, but the runtime configuration (with its dependencies) for execution to keep your compile class path as small as sensible and thus speed up the build and increase likeliness for up-to-date, for example if only a runtime dependency changed.
But in this specific case there are only compile, test, and provided dependencies anyway.