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).

- package splitting:  This happens
quite a bit.  Package P is developed and contains types for several
different functions - the developers imagine these always going together.
 Over time there is a need to move some of the types to other plugins
and other packages.  So, for example, P.T => Q.T or even Q.U.  Here
all references to the old type should change.  Return types, input
args, constructors, fields, vars, ...

- functionality moves.  Some method
M() moves from type T to U.  Typically now we have to create U.M()
and deprecate and maintain T.M().  In some cases the function is exactly
the same/compatible its just in a different place.

This is just some thoughts off the top
of my head.

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