I was writing a response in bug
210558 and thought it could be of interest to the whole CDT
community. So I'm copying it here and to platform-debug as well.
(In reply to comment #11)
> Man, that is ironic and unfortunate. Is there a proposal on the
> address the flexible hierarchy issues or does it need more
> Just wondering when we can expect to finally get rid of our use of
Right now all the flexible hierarchy interfaces are still a provisional
API. And I think the biggest issues to making them final has been
maturity and resources. This is also a big issue for DSF and for any
debugger which uses these interfaces. As 3.4 is third point release
that these APIs are in, I expect (hope) that they will finally be made
official in 4.0.
Like I said though, even if these APIs become official, some of the
classes that the Modules view integration requires are still plugin
private: DefaultModelProxyFactory, DebugTargetContentProvider, etc.
These classes are something of a problem for platform because due to
their design, as a public API they could be difficult to evolve and
maintain. However, any debugger trying to extend standard debug model
and use flexible hierarchy needs to either extend or copy these default
implementation classes. I think this question will also need to be
answered when the flexible hierarchy APIs go official.
Personally, I think there's another way to address this problem: to use
UI part of DSF to implement the default flexible hierarchy providers
for the standard debug model. However, DSF uses wrappers and this
would certainly break the backward compatiblity with the current APIs.
Still, the DSF-based default providers should be easier to maintain as
an API so it should be easier to make them public. I've been tempted
to try to implement this over the last year, but Wind River doesn't
really have a business reason for this functionality. Perhaps if
anyone else has this problem, they could investigate this solution with