Baseline Repo exclude from the build path

GENERAL
1

Is there a way to exclude the baseline repository from the repositories available at build time. It really has nothing to do with building and just using the highest version does not handle the case where a bundle is removed from “build” repository (ie you still see the release bundle)

And

When you are in bndtools and adding items to the build path , it should not show up there either

2

Yes, it would be nice if we could tag repos and then use these tags to limit their scope for different situations.

Currently we have nothing like this in place …

You’re willing to make a PR or fund the functionality?

3

I could do a PR.

If you are just restricting reops that are in the -baseline, -releaserepo is it not just a matter of using that as your filter ? In Workspace.java you just need add an internal method that get all’s all repos (for searching by name init) and then have List<RepositoryPlugin> getRepositories() filter out repos listed in the two options?

4

If you are just restricting repos that are in the -baseline, -releaserepo is it not just a matter of using that as your filter

The problem is that -baseline and -releaserepo can (and are) set on per project basis. Normally the baseline is set on API projects. The repo selection happens on Workspace level.

I think we need to define this as a tag on the plugin. If we define a PluginTags interface and adapt the repositories we could tag the the plugins for the repos. We can then easily define predefined tags for:

  • buildpath
  • testpath
  • baseline
  • release
  • resolve
  • commands
  • generate
  • etc.

This, I think, is easier to extend and easier to setup? Wdyt?

5

Ultimately the workspace is holding the plugins/repositories so having to scan the projects to get the values is not a showstopper. I am not sure in a workspace where one project has a repo marked as -baseline that it would be a build repo for another project. I was just looking for a quick and dirty solution. I agree your solution is the correct one but much more intrusive. A few thoughts …

  1. You would have to support multiple tags per repository (For example buildpath and testpath would seem a logical grouping)
  2. Workspace.getRepositories() should become private and we need to add separate methods for each type of repo. (getBuildRepositories(),getTestRespositories() … etc) This would be a VERY breaking change but from a design point of view correct and would make sure that all spots that touched the repositories were changed and any additional types added would follow the same pattern.
6

I think it is not that much work. We should specify a string format for the tags (which is basically a comma separated list). This can be a property on the plugin, we get all those via setProperties in the Plugin interface.

    aQute.bnd.repository.maven.provider.MavenBndRepository;\
        tags = "baseline,release"; \
        name="Maven Central";\
        releaseUrl="${mavencentral}";\
        snapshotUrl="${ossrh}";\
        index="${.}/central.mvn";\
        readOnly=true,\

The plugin should then implement a Tagged interface. On this interface we can make convenience methods that turn this in a set, etc.

We then extend the getPlugins(Class) and companions with String …

            getPlugins(MavenBndRepository.class, BUILDPATH_TAG, "all")

This would mean that it requires tag “abc” AND “def”. We could support ! for not.

On the Tagged interface we could make static methods to create more complex expressions but I do not think they’re needed to start with. With our filter we can make fancy expressions though :slight_smile:

The Workspace.getRepositories can also take the list of tag names.

The Project.getBundle() also need tags then, this is called from the places where get the Container lists to populate the paths.

Would be nice to support the tagging on the list of repositories in the (-repo I think) bndrun files. This is now always a bit of a pain in the ass with the ugly names repos tend to get.

Workspace.getRepositories() should become private and we need to add separate methods for each type of repo. (getBuildRepositories(),getTestRespositories() … etc)

This is clearly not the way to go. The places where we build the paths are I think only once and they can provide the proper tags to a new getBundles() method.

Transitioning is going to be interesting. Clearly the tags are not going to be there from the start so we need a strategy that when no tags are set on the plugins, it should work like today. We might have to set a default set of tags when tags are not supported. This includes then all tags used in the Workspace/Project.

7

Now we are on Java 17 we should use Enums not Strings.

Do all the repositories not extend BaseRepository ? Then you could just set the property there with a default for “all”? Cleans up the filter as well since the default case would be to just use the ALL enum. This would then exclude anything that was actually tagged.

Are we using the name “tags” as the property? We should use a more descriptive name …
useBy?, onlyFor ?

Then it would read useBy/onlyFor = baseline,buildpath etc …

8

Ouch! No way enums! :slight_smile:

This stuff needs to be extendable by user defined tags. Plus we should enable lots of fancy stuff will require a string format.