This wouldn't be an issue if the add-on specific code is moved to a different Jenkins plugin. Just have a look at
this, how it can work.
If we leave the support for both Bitbucket Cloud and Bitbucket Server within the "Bitbucket Branch Source" plugin I'd suggest the following changes to improve the maintainability:
1. implement a BitbucketCloudSCMSourceNavigator and a BitbucketServerSCMSourceNavigator that share the same base class but have the tool specific implemented in itself (e.g. retrieving the correct client implementation). With this you don't need to distinguish based on the URL or some other user provided input whether to talk to Bitbucket Cloud or Bitbucket Server. You'll always know this information depending on the context.
2. Do the same for the SCMSource
3. Replace the current "REST client implementation" by using JAX-RS (see
BitbucketServerAPI.java,
BitbucketServerClientService.java). The current implementation is error-prone. E.g. URLs get generated using String.fromat which means you have to care for proper URL encoding of path parameters yourself. You have to map status codes of error responses manually to exceptions. JAX-RS does this out-of-the-box. And last but not least. JAX-RS provides an easy way to read the whole request/response to add it the the log (see
LoggingFilter.java) which is very useful if some request failed.
I know that 1. and 2. will lead to some migration effort but this can be done automatically by the plugin within an initialisier. I did something similar already within the gitlab-plugin.
I don't know how your time schedule looks like but if you like I can support you reaching the above points. But as not everything of the plugin is covered by tests it could take some time to be sure I don't break any existing functionality.
Nevertheless I'll install my plugin for the moment in our Jenkins as this is working with our Bitbucket Server and will save the whole department a lot of time.
Regards,
Robin