[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-debug-dev] Custom debugger integration: flexiblehierarchy and asynch viewers
|
(1) We
(Adobe Flex Builder) do use the Eclipse 3.2 internal implementation in the Flex
Builder update that we'll be shipping soon.
(2)
However, we did this with the full understanding that our implementation might
not work in Eclipse 3.3, which means that our users wouldn't be able to use 3.3,
and that we would have to release another update at some point after Eclipse 3.3
is released.
Our
plugin is marked to only load if org.eclipse.debug.ui is version 3.2.0 or
greater; I considered having it only load for versions [3.2.0, 3.3.0), but I
didn't know if the 3.2 API would continue to work in Eclipse 3.3, and I decided
that if you guys didn't change the API in 3.3, I wanted our plugin to continue
to load. So I used [3.2.0, 99.0.0).
- Mike Morearty
Developer, Adobe Flex
Builder
Debug
community,
During the 3.2 release,
the debug platform developed and released new infrastructure to support
flexible element hierarchies in the debug viewers. As well, content and label
generation for elements in the viewers was moved to background (non-UI)
threads and supported cancellation. This infrastructure has been instrumental
in allowing the DSDP project, its participants, and other debug ISVs to
utilize the debug platform. In 3.2, the support was released as internal
framework, with the disclaimer that anyone who used it would be broken when
the framework evolved to its public form.
For 3.3, our goals was to publish the framework as a public API. In
doing so, we've improved the implementation (in a branch) to leverage the
JFace viewer code base. As well, we've confirmed that the viewer
implementation is generic and should not live in the debug platform. Others
would like to use the framework for non-debug purposes. Ideally, we'd like to
find a home for the viewers outside of the debug plug-ins. We'd also like to
ensure that we're not duplicating efforts/APIs. To find the right home for the
framework and ensure that we have consistent APIs and functions in the Eclipse
platform may take longer that the 3.3 release.
We don't want to publish an API in the wrong place. So,
if we can't find the right home for the framework, we'd like to keep the
framework as an internal implementation for 3.3. We don't want to cause
unnecessary pain for those that are already using the framework. At the same
time we'd like to use the improved implementation in 3.3.
So the questions for the community are:
(1) Who will break if we change the internal
implementation? (Our feeling is that not many are actually using the 3.2
internal API yet, except for experimentation)
(2) What are the implications if we provide a different, but internal
implementation in 3.3?
Thanks,
Darin
Wright