Re: [equinox-dev] support for component API refactoring

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

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 
        http://help.eclipse.org/help30/topic/org.eclipse.platform.doc.isv/porting/eclipse_3_0_porting_guide.html
and @deprecated directives we put together
in 3.0 and the migration guide we are starting for 3.2 
        http://eclipse.org/equinox/documents/3.2-migration.php

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.

Jeff

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

11/25/2005 04:26 PM

Please respond to
Equinox development mailing list

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	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
you?

-Martin



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
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev