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
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
Re: [equinox-dev] support
for component API refactoring
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
> bundle markup gives you enough information to figure out where exactly
> each referenced class will come from. With this info, you should
> to correctly apply the transformations without accidents. You
> to do an analysis to see that the set of "new" classes does
> the set of existing classes but that should be pretty straightforward.
> As for BCEL and ASM, yes, you would want some abstraction above this.
> wonder if there are any really simple tools out there since the sort
> transformations (at least initially) envisioned here are very simple
> (e.g., add some constant pool entries and change some constant pool
equinox-dev mailing list