Hello. I’m migrating a repository from PDE to BND+Gradle (not Bndtools yet). I have applied the biz.aQute.bnd.workspace Gradle plugin and I now have several bundles being built by BND in subprojects.
For complicated reasons, I’m not free to rename the subproject directories. They’re called things like api and impl and each bnd.bnd has a Bundle-SymbolicName entry setting the BSN to something longer. I’d like to use the BSNs for the Gradle subproject names, but those seem to be immutable once the workspace plugin has set them up.
When I first set up the impl bundle with com.ejjcase.myproject.api on its buildpath, I got the error
Can not find URL for bsn com.ejjcase.myproject.api
I worked around this by changing the buildpath entry to com.ejjcase.myproject.api;project=api. But now I’m getting the same error when running a TestOSGi task.
This time it’s reading the runbundles in a bndrun file that was generated just beforehand by a Resolve task. The runbundles has version snapshot for each bundle in the workspace, so BND knows it needs to look in the workspace, but because runbundles is generated without the project attribute I put in buildpath, BND doesn’t seem to know where to look.
What’s the right way to teach BND to locate bundles in the workspace when their BSNs don’t match their subproject names? I’ve been wondering if a repository is the right way to connect them together, but when I look at the BND code, BND doesn’t seem to query any repositories once it sees that a bundle’s version is snapshot.
Somebody here hopefully can point out a trick with the Gradle plugin but in generally I advise strongly against fighting a tool on something this fundamental. From my 50 years of experience I know how large barriers might loom to do it right (rename the directories) but from hindsight they always look silly.
Couldn’t you create a workspace directory that links the files with their proper BSN name?
Then again, maybe someone with the Gradle bnd non-workspace plugin might have a solution, I do not know much about it.
1 Like
Yes, I think I’m going to have to bite the bullet and rename the directories. I actually did this in the first Bnd Workspace project I converted, just for neatness, but it was such a hassle (breaking the legacy automated build and annoying the rest of my team) that I decided to try not to do it again.
I don’t want to work around this with any Gradle tricks because I want to make it possible for my team members to use Bndtools later if they want to, once the PDE build is gone.
Thank you for telling me this is fundamental. In my Bnd journey so far, I’ve generally found it hard to discover what assumptions Bnd is making, especially when they are different from the assumptions of PDE or ordinary Gradle projects. Then I waste a lot of time looking for fixes that don’t exist, before eventually accepting I have to do it the hard way. (For example, in PDE I can just tell the JUnit test runner to run all the tests on the Eclipse UI thread, but in Bnd each test has to go onto the UI thread of its own accord. I could not find this documented anywhere, and at first I found it hard to accept that I would need to make so many changes.)
I suppose it’s the use of a Bnd Workspace that makes the directory name matching a requirement. It wasn’t a requirement when I added biz.aQute.bnd.builder to a lot of ordinary Gradle java-library projects in order to make them usable as OSGi bundles. It wasn’t even a requirement when I added TestOSGi tasks to those projects. And it certainly isn’t a requirement in PDE.