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!

Related Query

More Query from same tag