Community
Participate
Working Groups
Currently, the constants for the attribute keys are in org.eclipse.pde.internal.ui.launcher.ILaunchSettings, which is internal to the PDE. We would like to request that these be made public API. Here's why. The Hyades profiler would like to support profiling the runtime workbench, which means launching your launch configurations in "profile" mode. In order to do this, our launch configuration delegate needs to be able to read your launch configurations.
I'm not sure why, but bugzilla doesn't email anyone if I enter CC's while opening the bug (a bug in bugzilla?). Anyway, here's your email.
What kind of useful information could be retrieved from their values? Their values only make sense for PDE that uses them to determine the arguments with which to launch the runtime workbench. These program argumens are interesting, and can be readily viewed in the Debug view. Unless I'm missing something, it does not make sense to expose the values for the keys in question.
In order to launch a VM in profiling mode, we have to pass the VM argument - XrunpiAgent. This is similar to what the debugger does to launch in debug mode. Your workbench launch delegate accepts "debug" mode, and simply asks the VMRunner to launch in this mode. The JDT's standard VM runner knows what to do with "debug" mode and adds its VM arguments just before launching. Unfortunately, we cannot do the same with "profile" mode because the standard VM runner is not extensible, and is hardcoded to handle only "run" and "debug" modes. Even if it were extensible, your launch delegate does not support the "profile" mode. This leaves our profile mode delegate with two basic options: Either read the launch configuration and launch the workbench ourselves, or add our VM arg to the launch configuration then delegate in "run" mode to your launch delegate. Unfortunately, for internal reasons it doesn't appear that the latter is feasible for us. This leaves us with launching the workbench ourselves, which is admittedly a bad solution, but the only feasible one I can see at the moment.
>This leaves us with launching the workbench ourselves, which >is admittedly a bad solution, but the only feasible one I can see at the >moment. You will not be able to do anything even if you had access to these arguments. PDE does not just pass them in. For each key, PDE does a certain amount of processing to determine what program argument to add, what file to generate, what directories to generate for the runtime workbench, etc... Are you also planning to use/copy the PDE code that actually processes these arguments?
I was just going to ask about this. How opposed would you be to providing access to this processing?
We've been experiencing build problems recently relating to internal API changes in your launching code.. Currently we are duplicating all of your private methods in WorkbenchLaunchConfigurationDelegate and relying on other internal classes in order to profile the workbench. Again, I realize this is very bad, but unfortunately it's either this or no workbench profiling. I understand a good solution can't happen quickly, but I think there's a quick fix that would improve our build stability, for now; by changing all private access in WorkbenchLaunchConfigurationDelegate to protected, allowing us to subclass and inherit most of the processing. Would this be possible in the near- term?
>We've been experiencing build problems recently relating to internal API >changes in your launching code.. No such thing as internal API, only public API. Classes are either designed and meant for public consumption or they're not. In this case, they are not. >I think there's a quick fix that would improve our build stability, for now; >by changing all private access in WorkbenchLaunchConfigurationDelegate to >protected, Making private members/methods protected just to let you subclass internal classes is not a solution. It will effectively make all these classes API. We want to have the freedom to change our code whenever we want without being blamed/held responsible for breaking or compromising the stability of your build. There is no plan to make the launcher code/constants/tabs public API in 3.0.
Wassim, our intention is to support profiling the runtime workbench and to be able to do that, we must read the eclipse runtime configuration. Since this is a critical usability feature for all products shipping Hyades, such as RDJ, we do need a solution soon.
Then we need a better explanation/justification for the urgency of this request. So far, all I've heard is that you want to expose to the user values of some internal launcher constants that only make sense for PDE anyways, and mean nothing to the user. This alone is not going to cut it at this stage in the game.
I find Curt's explanation pretty reasonable, this is a copy/paste from the defect description : 'The Hyades profiler would like to support profiling the runtime workbench, which means launching your launch configurations in "profile" mode. In order to do this, our launch configuration delegate needs to be able to read your launch configurations.' I think a face to face discussion would help us get the bigger picture. I'll try to book a meeting with you soon, maybe tomorrow or Friday; thanks
As Valentina describes, in the current state it is NOT possible to perform profiling or runtime analysis for the runtime workbench. This leaves the unusual situation of providing function to users to perform runtime analysis/profiling for applications within a workspace and also external to the workspace (via an attach) but not providing this function for users developing Eclipse plugins with PDE. This makes it difficult for developers creating Eclipse plugins to make use of existing Hyades performance analysis (and 3rd party performance analysis) tools.
Can you please set a target for this? I'd like to see this as soon as possible since it's causing problems for us.
Switching to a more appropriate summary. I leave the design up to you; we want to inherit the processing of the launch configuration attributes in order to launch the workbench in a different mode, with additional VM arguments. This is really all it boils down to. Right now there is no way to inherit any of this PDE functionality other than by using its internals (non-API).
Any progress on this? Can you please target?
Let's try this once more.. Any progress on this? Can you please target?
Fixed to Curtis' liking.
Verified with the latest code in HEAD.
Closing bugs that were previously verified.
