[equinox-dev] support for component API refactoring

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

To date we have operated under a 100%
binary compatibility rule with an underlying assumption that the original
code itself could not be modified.  Over time our API has become ladden
with old methods, old package and class names, old extension points, ...
 The challenge is keeping the API fresh, clean and clear while not
breaking existing code which, according to the assumption, cannot be changed.

The importance of API maintenance should
not be underestimated.  It is vital both for the smooth consumption
of components as they evolve but for its effect on producer/consumer trust.

With that in mind, it may be interesting
to challenge the assumption the consumer's code cannot change and instead
assume that the consumer does not change the code -- allow the producer
change it for them.  This direction was discussed amongst a number
of us at the OSGi World Congress a few weeks ago.  There are several
flavours but here is the basic idea.

- The producer of an API, for example,
changes the name of a package/class/method from A to B
- the producer also creates an aspect
definition that "co-opts" all consumers and modifies references
to the old package/class/method to reference the new package/class/method.
- this can capture package, class and
mehod changes
- there are corner cases involving reflection
and OSGi service lookup etc that may be more challenging

Similarly, a registry munging mechanism
would be required to update extension/extension point usage in the face
of renamed or refactored plugins.

Is there any interest in looking at
this problem (I'm thinking specifically from the aspect folks).  Thisis
a pretty mundane use of aspects but it would be hugely useful.

Jeff