bnd icon indicating copy to clipboard operation
bnd copied to clipboard

[arch] Deprecate custom extension points for use in Bndtools

Open kriegfrj opened this issue 4 years ago • 2 comments

For discussion:

Since experimenting with the "facade" pattern in the core Bndtools implementation, I have come across a few custom extension point definitions that are part of Bndtools. The most recent one that I discovered was for the IValidator interface. (Note: I'm not talking about custom implementations of existing extension points, but where we have both defined and used our own extension points.)

I think I have come to the conclusion that there are not any strong use cases for us to use custom extension points within Bndtools. Declarative Services can do the same thing, but they are easier to implement, maintain and deploy (particularly when Bnd is your build tool) and enable dynamic re-deployment (which isn't much help for the end user but it super-helpful for the developer). ServiceTrackers (and now even the ExtensionFacade) can be used to interface non-DS clients with DS implementations - and at the very least this is no more complicated than using the Eclipse Registry API to interface with extension implementation (and I would argue probably less complicated).

Assuming we agree to the above, then:

  1. we agree not to add any new custom extension points to Bndtools;
  2. we remove the existing custom extension points and replace them with DS implementations as we have the time/energy/motivation. If we feel it is necessary (as the extension points are technically part of a public API for Bndtools), we do this after formally deprecating them; Perhaps this would require a major version change to Bndtools. However, I doubt there are too many 3rd-party plugins out there that are extending Bndtools using these extension points - they are mainly for internal use (I think), so we might be safe with a minor version increment.

Thoughts?

kriegfrj avatar Dec 20 '21 06:12 kriegfrj

  • No custom extension points – Fully agree
  • Deprecating – After we've got a replacement, we can deprecate them, but we should then have at least one major release in between before removal imho. They cost little and even one annoyed customer is one too many.

pkriens avatar Dec 20 '21 07:12 pkriens

As for deprecating for removal. I am not convinced that anyone but ourselves have even implemented one of the Bndtools extension points. I am not sure we need a drawn out process to remove them. I would suggest we deprecate and cease using them immediately and state that they will be removed in the next major release.

bjhargrave avatar Dec 20 '21 14:12 bjhargrave

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

github-actions[bot] avatar Dec 21 '22 02:12 github-actions[bot]

This issue has been automatically closed due to inactivity. If you can reproduce this on a recent version of Bnd/Bndtools or if you have a good use case for this feature, please feel free to reopen the issue with steps to reproduce, a quick explanation of your use case or a high-quality pull request.

github-actions[bot] avatar Jan 11 '23 02:01 github-actions[bot]