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

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


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