Blocked by bndtools/bnd#5695

Hi Marc, after debugging yesterday, Sterling and I determined that this failure is caused by a change in what was thought was merely an internal behavior in Gradle 8.2. However, BND is unfortunately relying on the old behavior.

I'm going to submit a PR to BND next containing a proper fix for them. The PR here will workaround this issue and should work with Gradle 8.1.x as well as >= 8.2-rc-2. It will eagerly configure the Jar tasks in the JUnit 5 build to avoid the timing issue causing this failure, at the expense of only some minor unnecessary configuration when not running these tasks in a build.

What's meant to be happening is this:

1. In the constructor for BundleTaskExtension BND calls the setSourceSet method here.
2. This calls the jarLibraryElements method passing the main compileClasspath configuration. This method attempts to set the LIBRARY_ELEMENTS_ATTRIBUTE to the value jar here.
3. Using the value jar during dependency resolution ensures that the junit-platform-runner project gathers jar files built by other local JUnit subprojects it depends upon in its compileClasspath.
4. When BND is looking to build the list in the Import-Package property in the MANIFEST.MF file it creates, it reads this version from the Export-Package property in dependencies' MANIFEST.MF files. This manifest file is only available on the compileClasspath to read if the depednencies' jar files containing it are present. If the classes variant of the dependencies is selected rather than the standard variant containing jar files, only the compiled classes are available on the classpath, BND won't be able to determine version information to write.

What's happening now after the change:

A change in Gradle 8.2 to DefaultRootComponentMetadataBuilder#getRootComponentMetadata here caused this process to fail. Previously, we had looked at every configuration and its artifacts when building the root metadata when building the dependencies graph. This caused the Jar task building those artifacts to be realized, which caused the BundleTaskExtension to run, which caused the jar value for LibraryElements to be set, which allowed jars to be selected in the compileClasspath, which was needed for BND to see the versions to write as described above.

Due to the now lazier behavior when building the root metadata, Jar tasks that are required to build the artifacts supplied by a configuration are no longer realized prior to the beforeLocking callback running for those configurations.

This is meaningful because by default, Gradle would substitute the secondary classes variant that supplies the directory containing the compiled classes for local project dependencies. This would allow the compilation of this project to begin slightly earlier, without waiting for its local project dependencies' library files to be assembled first. Gradle accomplished this here. (Note that this method was just removed from master - the fix in the PR I linked will work with or without it present).

When the beforeLocking callback does run, the if check sees a value already is present for LibraryElements and if so, does nothing. So that value is already jar, the callback won't set it to classes.

Summary

Whether BND works or not ultimately comes down to whether Jar tasks are realized before or after the beforeLocking callback runs.

This is clearly not a requirement a build author should be thinking about, especially as the the order that configurations are iterated in beforeLocking is also meaningful here. Fro instance, if the compileClasspath had been named such that it came alphabetically ahead of archives (for instance aCompileClasspath), then this behavior would never have worked in Gradle 8.1.1, since then the beforeLocking callback also would run prior to the Jar task being realized, and we'd see the same behavior as in Gradle 8.2.

Hopefully this makes sense and this fix works for now, until BND can be also be fixed.