Why would adding the java plugin help to resolve dependencies?

Help/Discuss
1

I have a multi project setup where I build multiple jar and I need to copy them to a folter inside an ear file.

configuration {
   jar
}

dependencies {
   jar project(path: ":project1", configuration: 'default')
   jar project(path: ":project2", configuration: 'default')
   jar project(path: ":project3", configuration: 'default')
}

tasks.register('zipwildfly', Zip) {
...
  from(configurations.jar) {
     into '/lib'
  }
...
}

The projects has load of dependencies and end up needing quava.

And I get this output

Execution failed for task ':edelivery-broker-ear:zipwildfly'.
> Could not resolve all files for configuration ':edelivery-broker-ear:nisse'.
   > Could not resolve com.google.guava:guava.
     Required by:
         project :edelivery-broker-ear > project :edelivery-cxf
      > Unable to find a matching variant of com.google.guava:guava:33.5.0-jre:
          - Variant 'androidApiElements'
          - Variant 'androidRuntimeElements'
          - Variant 'jreApiElements'
          - Variant 'jreRuntimeElements'
   > Could not find org.apache.httpcomponents:httpclient:.
     Required by:
         project :edelivery-broker-ear > project :edelivery-cxf
   > Could not find commons-collections:commons-collections:.
     Required by:
         project :edelivery-broker-ear > project :edelivery-cxf
   > Could not resolve com.google.guava:guava:33.5.0-jre.
     Required by:
         project :edelivery-broker-ear > project :edelivery-cxf > org.apache.cxf:cxf-rt-ws-security:4.1.4 > org.apache.wss4j:wss4j-ws-security-common:4.0.1
      > Unable to find a matching variant of com.google.guava:guava:33.5.0-jre:
          - Variant 'androidApiElements'
          - Variant 'androidRuntimeElements'
          - Variant 'jreApiElements'
          - Variant 'jreRuntimeElements'
   > Could not resolve com.google.guava:guava:33.0.0-jre.
     Required by:
         project :edelivery-broker-ear > project :edelivery-cxf > org.apache.cxf:cxf-rt-ws-security:4.1.4 > org.apache.wss4j:wss4j-ws-security-common:4.0.1 > org.opensaml:opensaml-saml-impl:5.1.6
         project :edelivery-broker-ear > project :edelivery-cxf > org.apache.cxf:cxf-rt-ws-security:4.1.4 > org.apache.wss4j:wss4j-ws-security-common:4.0.1 > org.opensaml:opensaml-xacml-impl:5.1.6
         project :edelivery-broker-ear > project :edelivery-cxf > org.apache.cxf:cxf-rt-ws-security:4.1.4 > org.apache.wss4j:wss4j-ws-security-common:4.0.1 > org.opensaml:opensaml-xacml-impl:5.1.6 > org.opensaml:opensaml-core-api:5.1.6
         project :edelivery-broker-ear > project :edelivery-cxf > org.apache.cxf:cxf-rt-ws-security:4.1.4 > org.apache.wss4j:wss4j-ws-security-common:4.0.1 > org.opensaml:opensaml-saml-impl:5.1.6 > org.opensaml:opensaml-profile-api:5.1.6
         project :edelivery-broker-ear > project :edelivery-cxf > org.apache.cxf:cxf-rt-ws-security:4.1.4 > org.apache.wss4j:wss4j-ws-security-common:4.0.1 > org.opensaml:opensaml-xacml-saml-impl:5.1.6 > org.opensaml:opensaml-saml-api:5.1.6
         project :edelivery-broker-ear > project :edelivery-cxf > org.apache.cxf:cxf-rt-ws-security:4.1.4 > org.apache.wss4j:wss4j-ws-security-common:4.0.1 > org.opensaml:opensaml-saml-impl:5.1.6 > org.opensaml:opensaml-security-api:5.1.6
         project :edelivery-broker-ear > project :edelivery-cxf > org.apache.cxf:cxf-rt-ws-security:4.1.4 > org.apache.wss4j:wss4j-ws-security-common:4.0.1 > org.opensaml:opensaml-saml-impl:5.1.6 > org.opensaml:opensaml-xmlsec-api:5.1.6
         project :edelivery-broker-ear > project :edelivery-cxf > org.apache.cxf:cxf-rt-ws-security:4.1.4 > org.apache.wss4j:wss4j-ws-security-common:4.0.1 > org.opensaml:opensaml-saml-impl:5.1.6 > net.shibboleth:shib-security:9.1.6
         project :edelivery-broker-ear > project :edelivery-cxf > org.apache.cxf:cxf-rt-ws-security:4.1.4 > org.apache.wss4j:wss4j-ws-security-common:4.0.1 > org.opensaml:opensaml-saml-impl:5.1.6 > net.shibboleth:shib-networking:9.1.6
         project :edelivery-broker-ear > project :edelivery-cxf > org.apache.cxf:cxf-rt-ws-security:4.1.4 > org.apache.wss4j:wss4j-ws-security-common:4.0.1 > org.opensaml:opensaml-xacml-impl:5.1.6 > net.shibboleth:shib-support:9.1.6
         project :edelivery-broker-ear > project :edelivery-cxf > org.apache.cxf:cxf-rt-ws-security:4.1.4 > org.apache.wss4j:wss4j-ws-security-common:4.0.1 > org.opensaml:opensaml-saml-impl:5.1.6 > org.opensaml:opensaml-soap-impl:5.1.6
      > Unable to find a matching variant of com.google.guava:guava:33.5.0-jre:
          - Variant 'androidApiElements'
          - Variant 'androidRuntimeElements'
          - Variant 'jreApiElements'
          - Variant 'jreRuntimeElements'

But when I add the java plugin this problem goes away. :confused: . It was an idea that popped up because java dependencies I believe sets som attributes so that variants can be resolved. My initial attempt was to extend implementation. That does not seem to have any bearing on the issue. The java plugin solves the issue. And as you see I changed configurations jar to nisse and it behaves exactly the same.

What does the java plugin provide that solves the issue? I really want to understand more.

I think am on gradle 8.11.1 using java 21. I am in the middle of migrating from java 11 to 21 and to ee10.

2

It actually is not the java plugin that solves your issue, but the jvm-ecosystem plugin (which is applied by the java-base plugin which is applied by the java plugin).

The jvm-ecosystem plugin - amongst other things - configures various compatibility and disambiguation rules for the JVM ecosystem attributes.
For example for jvm environment attribute it configures to use standard-jvm if no exact match is found and a candidate variant has standard-jvm.
Similar for usage attribute, if no concrete value is requested, the runtime variant wins if one is in the candidates.
Theses two disambiguate the 4 candidates from the error message so that jreRuntimeElements is used.

If you want to resolve JVM dependencies, you should always at least apply the jvm-ecosystem plugin as it sets up the JVM ecosystem attributes, variant derivation rules, and so on, according to the JVM ecosystem.

3

Besides that you should anyway also request the JVM ecosystem attributes so that you get the right variants for your use-case.