[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-debug-dev] Extending launch configurations
|
Joe,
Although I understand what you are saying, this bothers me for a couple
of reasons.
First,
there is the effort involved on my part. I agree that by using helpers
classes and other tricks, I can reduce the amount of effort involved in getting
things to work. But, there is certainly more effort required than it seems
it should be. The things that I can think of (off the top of my head...)
include the launch config tab, the launch config tab group, the launch config
delegate and the launch shortcut. Depending on how this is done, parts of
these can and will be reused. But, in many cases the pieces are *almost*
exactly the same as the code that is already there in the
platform.
Second
is the performance impact of doing things this way. I may be thinking
about this wrong, but it seems like there is a lot of redundancy in order to add
a single launch config tab and some JVM command-line parameters. If I'm
stealing code, I'm increasing the footprint of the workbench and plugins which
is in direct conflict with the goals of the 2.1 development stream to lower the
memory required. I also wonder if I'm going to force the platform to
activate more plugins to make my coded extensions to PDE, etc. work as
necessary.
I
guess what I'm thinking would be nice is a set of extension
points:
1) A
tab group addition extension point that allows a new launch configuration tab to
be added to a named launch config tab group.
2) An
extension to somehow get some amount of control during delegation without being
responsible for the complete launch delegation procedure. Perhaps just a
way to alter/augment some well-known launch configuration attributes such as the
command-line parameters, etc.
Am I
crazy for thinking this? If not, I'm more than willing to write up a
feature request. On the other hand if this is not something that is a
common need then I will just trudge through the work as is.
Thanks,
Craig
Craig,
I don't think there
is any other way currently to accomplish the same task. Creating new
config types with associated new delegates IS the extension mechanism for
launch configurations. 'Stealing' JDT code isn't a problem, that's what
it's there for :-) As for reducing the workload for future config types
that require your profiling behavior, you can certainly reuse your profiling
tab for each config type, and you can also create an abstract delegate class
that has multiple concrete extenders, one for each config type that needs
profiling. In this way, I think you can make that task of creating a new
profiling config type very simple.
Joe
