3

I've written an Eclipse plugin that depends on version 1.0 of another plugin (let's call it WidgetMaster). Now, version 2.0 of WidgetMaster has been released with interface changes on many of the classes I was using. How can I continue to maintain one version of my plugin while supporting both versions of WidgetMaster?

So far what I've come up with is:

  1. Create my own interface for all the functionality provided by WidgetMaster. This means I'd also have to create wrappers for all of their types I was using, which is a lot.
  2. For each supported version of WidgetMaster, create a Fragment project that implements my interface and all the wrapper classes in terms of that version's API.

This is going to be a significant amount of work because I currently use WidgetMaster classes throughout my plugin code. If I will only be depending on a specific version of WidgetMaster from my Fragment projects, I will have to move and wrap all of that. Also, 99% of the wrappers will be the same from version to version but I'll still have to copy them to each Fragment.

Is this the right approach or is there a better way to handle this situation?

takteek
  • 7,020
  • 2
  • 39
  • 70

1 Answers1

1

The Adapter pattern seems like the right way, if you really want to provide continual support for the different versions of the WidgetMaster plug-in, for long term scope.

For a shorter support time, I'd duplicate the plug-in and leverage my version control system and its merging capabilities. I'd create a different branch that uses the most recent version of WidgetMaster. So I'd have two versions of my plug-in, each would use the different versions of WidgetMaster, calling to the specific version's API call. Make sure that your VCS has been informed of the merge resolution once it's all set so that future merges do not overwrite the API call customization (e.g. ours strategy with git merge).

The two different approaches have overheads but at different times. The Adapter approach has a bigger initial overhead while the VCS approach would be quicker to setup. But once the adapters have been implemented, the overhead is minimal, while the VCS approach will always have the merging overhead.

As a side note, I wonder if OSGi fragments are really the best option for you to setup the version to use of WidgetMaster (if you pick the Adapter approach). I am no OSGi expert, but you could look into OSGi service factories to give you the right version of WidgetMaster. There are more evolved ways apparently to accomplish dependency injection with OSGi: Apache Felix Maven SCR Plugin, Blueprint Container, Apache Felix iPojo. This SO question seems to cover the question of DI in OSGi.

Good luck! I'd like to know which route you take, as I'll face some similar challenge soon!

Community
  • 1
  • 1
jlr
  • 1,362
  • 10
  • 17