[JENKINS-53825] org.jenkinsci.plugins.github_branch_source.ForkPullRequestDiscoveryTrait and com.cloudbees.jenkins.plugins.bitbucket.ForkPullRequestDiscoveryTrait should be able to have the sam @symbol name

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

---
Originally reported by stephenconnolly, imported from: org.jenkinsci.plugins.github_branch_source.ForkPullRequestDiscoveryTrait and com.cloudbees.jenkins.plugins.bitbucket.ForkPullRequestDiscoveryTrait should be able to have the sam @symbol name

• status: In Review
  
• priority: Critical
  
• component(s): structs-plugin
  
• resolution: Unresolved
  
• votes: 1
  
• watchers: 3
  
• imported: 20260604-211335
  

Raw content of original issue

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