https://github.com/jenkinsci/scm-api-plugin/pull/55#issuecomment-425215058

So https://github.com/jenkinsci/scm-api-plugin/blob/5b5e58e70489167414b77fd1a7e8a92bf7b3e68e/src/main/java/jenkins/scm/api/trait/SCMTraitDescriptor.java#L84 gives us the knowledge that https://github.com/jenkinsci/bitbucket-branch-source-plugin/blob/9296189af7bab5c33ce09f17c66bfda70f7e2c2b/src/main/java/com/cloudbees/jenkins/plugins/bitbucket/ForkPullRequestDiscoveryTrait.java#L184 means to never offer com.cloudbees.jenkins.plugins.bitbucket.ForkPullRequestDiscoveryTrait to any other SCMSource

So in theory we could put @Symbol("discoverForkPRs") or similar on

• https://github.com/jenkinsci/github-branch-source-plugin/blob/master/src/main/java/org/jenkinsci/plugins/github_branch_source/ForkPullRequestDiscoveryTrait.java ; and
• https://github.com/jenkinsci/bitbucket-branch-source-plugin/blob/master/src/main/java/com/cloudbees/jenkins/plugins/bitbucket/ForkPullRequestDiscoveryTrait.java

However, if we do that, then the Symbol tooling throws its hands up in the air because all it does is look up the SCMTrait base class implementations and it would find two of them with the same name and throw its hands up in the air saying "I just don't care: use the full class name or go home"

It should be possible to enhance symbol support somehow to allow either:

• symbol libraries to solve the contextualization themselves (sounds like funky stuff using reflection on parameterised types); or
• symbol libraries would have a registry of context filters... and then scm-api could provide a context filter for traits that would use the scm-api specific information to narrow the list... and then much like The Highlander: There would be only one... and all will be right with the world again.

Also abayer is lazy and should have written this up himself