Bnd version: 7.1.0
Java version: 17
Gradle version: 8.14.3
OS: Windows 11

I have a Bnd workspace with many test bundles. Each test bundle project has a bndrun that runs the bundle's tests, and resolution is done dynamically. To reduce boilerplate, I added this to the shared bndrun that the others all import:

# Include the bundle that owns the entry point bndrun file.
-runrequires.tests: bnd.identity;id='${project.name}'

This works fine in Bndtools, but when I run the tests in Gradle, resolution fails because Bnd is looking for a bundle whose bsn is the name of the Gradle task.

Investigating, I found:

• ${project.name} expands to ${p}
• ${p} expands to ${basename;${project}}
• ${project} expands to ${basedir}
• ${basedir} usually expands to the project directory, but in an AbstractBndrun task, it expands to the task's workingDirectory.
• By default, workingDirectory is a temporary directory named after the task. This breaks Bnd's assumption that the project name and the directory name will match.

For now, I've worked around it like this:

tasks.withType<AbstractBndrun>().configureEach {
  workingDirectory = temporaryDir.resolve(project.name)
}

The effect is that instead of, for example, com.ejjcase.myproject.tests/target/tmp/testOSGi/, the working directory is com.ejjcase.myproject.tests/target/tmp/testOSGi/com.ejjcase.myproject.tests/. This gives the correct value for p and properties derived from it, but still gives each task a unique working directory.