[e4-dev] How to manage refactorings necessary to support the API

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

While looking into fixing 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=379024

We decided to eventually go with an
approach that delegates the default behavior back to the element's renderer
(so that we can implement the SWT 'forceFocus()'). Unfortunately this means
that the PartServiceImpl must have access to at least AbstractPartRenderer
which is currently in org.eclipse.e4.ui.internal.workbench.swt.

This is obviously not the place for
it since it's properly agnostic (i.e. contains no SWT imorts) *and* it's
not really 'internal' since it is part of the API we're declaring...

So now the question becomes where to
move it ?

For me since it's a part of the rendering
setup it should be under a new package (bundle?) "org.eclipse.e4.ui.workbench.renderers"
which is where we might also put any other platform agnostic rendering
stuff (including the PRE once we've cleaned it up).

Warning !!
Whatever we decide in this case we need an approach to this because as
part of making the API public there will be *significant * churn which
will likely affect both existing implementations as well as impacting Tutorials
/ Blogs... This is unavoidable, these classes cannot stay
in their current packages and at least some of them should be moved into
new bundles. The question is how best to do this with the least churn...note
that the case above is likely not the only one (we should be so lucky...;-).


The best idea I can think of is to do
this in as few passes as we can. I'm still gathering up the API bits into
a GoogleDocs presentation and I'll try to call out which classes have to
move and then we can decide on where they need to go...then we do the re-factoring
in one pass and update any public materials accordingly.

If anybody wants to make suggestions
as to the shape of the API packages / bundles *now* is the time,
Eric