[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] support for component API refactoring

Hey Martin,

I don't have a list. To date I have just been thinking out loud and relaying some of the conversations had in Paris and in the 3.0 dev cycle when some significant refactorings were done.

Most of the "easy" changes relate to things moving or being renamed.  A prime example of this is the recent refactoring of the Runtime.  We have had incredible problems doing this because we really want ot repackage the registry types and remove a few methods (that suck in some really old types).

The challenge here is to make all references to the old type morph into refs to the new type.  This includes return types, input args, constructors, fields, vars, ... There are also some cases where functionality gets broken up over several classes.  Rather than deprecating the old method, it would be more interesting to simply forward callers to the new method.  

Perhaps one way to approach this is to look at the migration guide
and @deprecated directives we put together in 3.0 and the migration guide we are starting for 3.2

Basically we would like to do these kinds of changes with much less impact on our users but also in ways that are much easier to implement and maintain for our development team.  Tossing dead/old code is a real bonus.


Martin Lippert <lippert@xxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

11/25/2005 04:26 PM

Please respond to
Equinox development mailing list

Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Re: [equinox-dev] support for component API refactoring

Hi Jeff,

do you have a list of API modifications that you would like to get
automatically adapted by such a mechanism? What would be most useful for


Jeff McAffer wrote:
> Clearly I have not thought deeply about this but superficially, the OSGi
> bundle markup gives you enough information to figure out where exactly
> each referenced class will come from.  With this info, you should be able
> to correctly apply the transformations without accidents.  You would have
> to do an analysis to see that the set of "new" classes does not overlap
> the set of existing classes but that should be pretty straightforward.
> As for BCEL and ASM, yes, you would want some abstraction above this.  I
> wonder if there are any really simple tools out there since the sort of
> transformations (at least initially) envisioned here are very simple
> (e.g., add some constant pool entries and change some constant pool
> references).
> Jeff

equinox-dev mailing list