I think you misunderstand the purpose of those paths being generated. They exist merely to document the result of the resolution, so that a downstream tool can use it to assemble a product out of the resolved resources. Using relative paths or an indirect protocol would defeat this purpose.

Neither Bndtools nor bnd use this information again; we only look at the BSN and version. Therefore I don't believe there is any problem with sharing these files through a VCS.

If you agree then please close the bug, otherwise comment further. Many thanks.

I was under the impression that the user may edit the -runbundles section manually even though it is not recommended, because of the warning visible in the run descriptor editor:

WARNING: directly editing this list is discouraged!! Instead use OBR Resolution from Run Requirements

The problem with sharing the file through a VCS is the following: suppose Joe creates a run descriptor, sets up the requirements and once everything's running well commits it to the repository. The file contains -runbundles section with paths specific to Joe's machine. Frank checks out the run descriptor, and runs the application. Now paths specific to Frank's machine are written to the file. The file lights up as modified, although Frank made no change that needs to be shared. Now Joe makes a change to the descriptor and commits it to the repo. When Frank does an update of his workspace the run descriptor lights up as a conflict. Now Frank needs to look carefully and merge Joe's changes in -runrequire section into his copy.

Here's my idea for improvement:

1. do not write -runbundles to the descriptor file at all
2. remove the warning in Run Bundles section.
3. add click action handler to the list elements in the Run Bundles section that would highlight the exact artifact that the bundle was resolved to in the Run Repositories section. This way all the information that the user could glean from reading -runbundle section in the descriptor file will be available

Okay I start to see the problem, but I don't think the suggested solution will work. Could I ask you to clarify:

1. do not write -runbundles to the descriptor file at all

Then we won't know which bundles to actually run. The -runrequirements list is not used at runtime.

1. remove the warning in Run Bundles section.
2. add click action handler to the list elements in the Run Bundles section that would highlight the exact artifact that the bundle was resolved to in the Run Repositories section.
   This way all the information that the user could glean from reading -runbundle section in the descriptor file will be available
   How will the tool know which artifact to highlight, if this information is not saved in the file?

I think perhaps a better fix would be to output the paths into a separate file under the generated directory. Comments?

Oh I see, this information needs to be written to the filesystem one way or the other, in order to persist the resolution results across workspace restarts.
generated directory is certainly an option, but I'd rather have it written to bndtools plugin's private directory inside workspace metadata. If think it good practice to avoid cluttering the workspace with anything that the end user doesn't need to see or share. Therefore writing bundle artifacts to generated is great - user can use them in various ways, but writing temporary files that the user has no interest in is not so good.
Another concern is that whatever is visible in the workspace is fair game for the users to modify - a hapless user might blow away contents of generated directory, and then complain that bndtools "forgot" the resolution results...
The same goes for /cnd/repo/.obrcache directory - if I understand things correctly it should not be shared through VCS, and the user has no business looking in there. If this is correct I'd suggest stashing it into workspace metadata. Further on that note, I'm wondering what /cnf/cache directory is for. Should it be shared trough VCS? Should it be visible / modifiable by the end user?

Before I get to the proposed solution, I'd like to state again what the original purpose of the runrequire and runbundles was for our team: we want to be able to perform an identical run inside and outside eclipse (in particular, deploy to a non-dev machine).
Assuming we perform the build within eclipse, running outside eclipse involves the following steps in our current solution:

• manual steps: configure the active repositories and their order, configure the framework and the execution environment, define runrequire
• manual trigger Resolve
• runbundles are computed and saved to the bnd file
• a separate ant task parses the runbundles from the bnd file, particularly the resolution info and copies the files to a configured folder (e.g. deploy/lib).
• run the application outside eclipse: launch an OSGi framework, install all bundles from deploy/lib, start them all, possibly also call a Main method on one of the bundles.
  Note: the fact that the project itself is missing from the runbundles is a problem, as we need to either manually add it to the deploy list, or the ant task has to infer this information from the other bits in the bnd file.

Is it possible that resolution uses paths relative to the configured OBRs? This would allow the information to be machine-independent, while a downstream tool could still find and deploy the bundles using the the known locations of each OBR.
Should there be any problems with this approach, I think a separate file inside generated (not put into VCS) is a good idea.

Thanks for your comments Marian. I don't think we could use paths relative to the configured OBRs, because when examining a path later we would not know which OBR is was relative to.

As far as I can see, putting this information into a separate file under generated is the most practical option.

Fixed in commit 4ab500c

Fix is as follows: on resolve, a file is created/updated with the name generated/<runfile>.resolved. For example if you are editing run.bndrun then the file generated/run.bndrun.resolved is used. Resolved resources are listed in the file with one resource per line. Each line is formatted as follows:

<bsn>;version=<version>;resolution=<path>

For example:

org.apache.felix.shell;version='[1.2,2)';resolution=http://example.org/repo/org.apache.felix.shell-1.2.2.jar