Gradle fails to resolve dependency net.bytebuddy:byte-buddy

[thokuest]

The following build.gradle snippet

dependencies {
    testImplementation platform("org.junit:junit-bom:5.6.2")
    testImplementation 'org.junit.jupiter:junit-jupiter-api'
    testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine'
    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
    testRuntimeOnly 'org.junit.platform:junit-platform-runner'
    
    testImplementation "org.assertj:assertj-core:3.16.1"
    testImplementation "org.xmlunit:xmlunit-core:2.7.0"
    testImplementation "org.xmlunit:xmlunit-assertj:2.7.0"
}

fails to resolve Byte Buddy with the following error:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':server:compileTestJava'.
> Could not resolve all files for configuration ':server:testCompileClasspath'.
   > Could not find net.bytebuddy:byte-buddy:.
     Required by:
         project :server > org.xmlunit:xmlunit-assertj:2.7.0

Which version of Byte Buddy do I need to include?

assertj-core itself depends on Byte Buddy already but shades the dependency into it's own jar.

[bodewig]

Depends on the version of Java. The parent POM lists 1.10.0 inside the Java7+ profile and 1.10.10 in the Java14+ profile. It looks as if Gradle didn't mimic maven when several active profiles contribute to dependencyManagement.

I think I added the 1.10.10 version in order to fix the builds on Java 14.

Honestly I haven't followed what @krystiankaluzny is doing with the help of bytebuddy in the assertj module closely, no idea whether unconditionally bumping the dependency to 1.10.10 will break anything. I guess we will see what Travis says: c261b72

[bodewig]

OK, that didn't hurt too much.

As I type a 2.8.0-SNAPSHOT build is going up to the Sonatype OSS Nexus. Can you please give it a try with Gradle to see whether it likes to work with that?

[thokuest]

No, this didn't work.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':server:compileTestJava'.
> Could not resolve all files for configuration ':server:testCompileClasspath'.
   > Could not find net.bytebuddy:byte-buddy:.
     Required by:
         project :server > org.xmlunit:xmlunit-assertj:2.8.0-SNAPSHOT:20200612.154140-1

Looking at the pom.xml, I'm pretty sure it's due to net.bytebuddy:byte-buddy being provided scoped. Hence the consuming project or any other dependency is expected to depend on it separately which also may make sense given the fast pace at which new Java versions are released and the role Byte Buddy plays here!

<dependency>
    <groupId>net.bytebuddy</groupId>
    <artifactId>byte-buddy</artifactId>
    <version>1.10.10</version>
    <scope>provided</scope>
</dependency

I wonder if Maven projects produce a different result.

With regard to profile support in Gradle, yes, Gradle supports Maven profiles to some limited extend.

Consuming Maven dependencies that rely on profiles

We have discussed the role of Maven profiles in configuring a build and alternative approaches in Gradle. As Gradle supports depending on POM-based artifacts we must also consider how Maven profiles affect dependency resolution.

Some published Maven artifacts, especially in the public Maven Central repository, depend on the information declared in their POM profiles for the dependency resolution process. Such a practice is considered to be an anti-pattern to be avoided as it influences the reproducibility of a build. Nevertheless, it is used in practice and Gradle 1.12 introduces support for some profile usage that affects dependency resolution.

Supported profile criteria in Gradle

There are two activation criteria Gradle considers:

1. Profiles that are active by default (available with Gradle 1.12 and higher)
2. Profiles that are active on the absence of a system property (available with Gradle 2.0 and higher)

From: Gradle's Support for Maven POM Files

[bodewig]

Any suggestion what we should change on our side to make things easier?

[thokuest]

I need to check how it works in Maven first. I keep you posted once I'm clear what can be done.

[bodewig]

@thokuest the doc snippet you've posted indicates gradle wouldn't support profiles triggered by JDK version, so I've now simply moved the dependencyManagement section outside of the profile and published new SNAPSHOTS. Could you please give the 20200729 SNAPSHOT a try?

[thokuest]

Thanks @bodewig! Will do once I'm back from vacation!

[bodewig]

Enjoy your vacation @thokuest :-)

[thokuest]

I just checked the latest snapshot build. I decided to setup a Maven project to check whether the build tool is important in some shape of form. The Maven build fails as well with a similar message indicating missing bytebuddy:

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running de.tk.XmlunitAssertjTest
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.097 s <<< FAILURE! - in de.tk.XmlunitAssertjTest
[ERROR] test  Time elapsed: 0.087 s  <<< ERROR!
java.lang.NoClassDefFoundError: net/bytebuddy/matcher/ElementMatcher
        at de.tk.XmlunitAssertjTest.test(XmlunitAssertjTest.java:10)
Caused by: java.lang.ClassNotFoundException: net.bytebuddy.matcher.ElementMatcher
        at de.tk.XmlunitAssertjTest.test(XmlunitAssertjTest.java:10)

See reproducer https://github.com/thokuest/xmlunit-issue-188-reproducer for your convenience.

Maybe it's an issue in the project, but isn't it so that transitive provided scope dependencies are not consumable?

[bodewig]

OK, so it seems we're breaking automatic transitive dependency resolution for bytebuddy and force people to explicitly depend on bytebuddy themselves, right?

@krystiankaluzny do you recall why you made bytebuddy provided in the first place?

[thokuest]

OK, so it seems we're breaking automatic transitive dependency resolution for bytebuddy and force people to explicitly depend on bytebuddy themselves, right?

Yes!

[bodewig]

I've changed the scope and am just now publishing new SNAPSHOTs, would be good if you could give it a try.

[bodewig]

2.8.0-SNAPSHOT, that is.

[thokuest]

Confirmed working with commit 8bb2221. Thanks a lot @bodewig!

[bodewig]

I've finally released 2.8.0, thanks @thokuest for the patience and for testing.