Add release extra bundles

I am not sure I understand? In my proposal there were already multiple extension per bundle/JAR in the repository with the where attribute?

This is the only solution to have an extension that can register itself inside the workspace. You need an anchor point. The where attribute allows you to define the root of the extension inside a bundle so you can have multiple extensions per bundle. However, the layout there is more than ok to have some fixed points like a workspace.bnd and project.bnd. This is similar to package.json, pom.xml, etc. Simple to use, easy to understand, and very familiar to any developer.

You seem to be thinking the wrong way around? The capability is inside the bundle that provides the extensionS in my proposal. Clearly they need a version? And I am not sure what the bnd.use.extension would do? Transitive?

From the workspace that wants to use the extension, you need to have some requirement so you can find it in the repository. The -workspace-extension in the build.bnd is the corresponding requirement, selecting the extensions. Each selected extension is copied to the cache and then the workspace.bnd file is read to install the extension. The -use is only for projects, and provide an activation of that extension for that project. I.e. the workspace.bnd would install a repository, the -use would augment the -buildpath et. al.

I do not think it should use parameters. The project.bnd in the extension would have full access to all the properties in the macro language. Keep it minimal, especially in the beginning.

Not necessarily, because we could use the bundle version here. Putting the Version in the capability however would make it easier to create the requirement without jumping through an extra hoop here. So, point taken.

True. I had similar feelings while I had the idea but I wanted to validate them.

Just a quick recap regarding the other point from my side to make sure, Iā€™m on the same page as you:

A Bundle provides one or more bnd.workspace.extensions. The where points to a folder in the bundle. If named by a -wokspace-extension, the folder will be unpacked somewhere in the cache. The folder requires at least a workspace.bnd that will then be included in the workspace, but may contain other files as well that can be references (e.g. an index file for a maven repository). I can apply further properties to a project bnd or a bndrun by declaring -use with the extension name. In this case a project.bnd must be present in the extension folder that then will be applied.

In this scenario I have one option for -use per extension. What I want to achieve is having more then one -use option per extension. In the scenario I have in mind the workspace.bnd would provide the repository with all my dependencies. It then want to provide different additional properties for different situations, that all require the same basic workspace configuration (in this case the available repo). Thus I would at least need multiple project.bnds that can be applied depending on the -use I define.

Why not use your own instructions:

  bnd.bnd:
  -use foo/bar, aQute/awesome
  -awesome gen-src/*

That way your extension instructions can be full blow Parameters, with the -use instruction they would need to be only attributes.

If anybody ever stumbles upon this, the discussion resulted in -library library ( ā€˜,ā€™ library )* | bnd