Community
Participate
Working Groups
TPTP is extending the following delegates and tabs to support profile mode. They are currently internal and some methods are private. We would like to request that these be made public API, as we have to duplicate some of the methods to support profile launch now. What TPTP does to support profile mode is mainly getting the launch argument/command, enable profile support Java argument, and launch with Agent Controller. org.eclipse.pde.internal.ui.PDEPlugin; org.eclipse.pde.internal.ui.launcher.EclipseApplicationLauncherTabGroup; org.eclipse.pde.internal.ui.launcher.JUnitTabGroup; org.eclipse.pde.internal.ui.launcher.JUnitWorkbenchShortcut; org.eclipse.pde.internal.ui.launcher.JUnitLaunchConfiguration; org.eclipse.pde.internal.ui.launcher.LauncherUtils; org.eclipse.pde.internal.ui.launcher.MainTypeSelectionDialog; org.eclipse.pde.internal.ui.launcher.RuntimeWorkbenchShortcut; org.eclipse.pde.internal.ui.launcher.SWTApplicationLaunchShortcut; org.eclipse.pde.internal.ui.launcher.EquinoxLauncherTabGroup; org.eclipse.pde.internal.ui.launcher.EquinoxLaunchShortcut; org.eclipse.pde.internal.ui.launcher.VMHelper; org.eclipse.pde.internal.core.PDECore; org.eclipse.pde.internal.core.util.CoreUtility;
This is a very ambitious request, especially when it comes to asking for bundle activators such as PDECore and PDEPlugin API. You will need to be specific on what you use from all of these classes.
Note that the API cut off is basically passed.
Past API freeze and more information is needed. Deferring to post-3.2.
Hi. I am reopening this request and understand that the API is frozen in this release, but please target to a future release. The whole idea of the request is not just to make the list items public, but to enable existing launch configurations to better support profile mode. In TPTP, launch delegate in profile mode requires all the user inputs (from tab in run mode plus additional tab in profile mode), parse them and launch it with TPTP Agent Controller framework. The limitation is that we have limited access on the information that is composed by the PDE code, and with the requirement of launching by our own, we need to override the launch() method which requires internal access on PDE code.
The current APIs are sufficient for any profiler to do its job. If they are good enough for Yourkit and other profilers, they should be good enough for you. If you have the need to do all that parsing, then you're probably doing something you're not supposed to be doing. For example, a lot of logic/parsing goes into constructing the program arguments by PDE, but if you override getProgramArguments() in the PDE launcher and call super.getProgramArguments(), you get it all for free without any parsing of your own. So if I were you, I would re-examine my code and see if I really need these APIs. You would then go back and really justify every API request in comment 0. Then and only then, we could judge if the request is legitimate and size/target it. Right now, the request is too ambitious. I asked for detailed clarifications in comment 1 and never got it. I will resolve again as LATER. Reopen once you do your investigation and come back with an answer/justification for every API request you list in comment 0. We will not commit to anything until you do so.
Hi Eugene, We are planning some more of the launcher classes API (ie. the ones pertaining to the Eclipse Application launcher and the Equinox (which will be renamed to OSGi) launcher soon. most likely for 3.3 M2. As for the SWT-launcher-related stuff, as it stands now, I don't think it is worth making them API. JDT/SWT keep having talks about finding alternatives to the launcher (bug 122527) and asking PDE to remove it. The last thing that remains on your list is some PDE-internal stuff, which would take a long time (years) to make API. Some classes (eg. activators) are not even recommended to be made API. I need to get an idea of how you are using these internal classes, as we may be able to find you alternatives (ie. you may be doing things the hard way) or we could refactor our code so that you could have more power overriding thing and not re-computing things. As I pointed out before, other profilers, like Yourkit, do not need access to these classes. So I doubt that you do. Can you point me to the TPTP plug-ins that extend the PDE launchers?
Hi Wassim, The TPTP plugin that make internal calls is org.eclipse.hyades.trace.ui, downloadbale at http://www.eclipse.org/tptp/home/downloads/downloads.php?link=link2&ver=4.3.0 In TPTP 4.2, the launcher code is refactored and all the internall calls are group under a single utility class. org.eclipse.tptp.trace.ui.internal.launcher.core.LauncherUtility. I will attach the class file here.
Created attachment 49657 [details] LauncherUtility Please see in this class file the list of internal api being called from TPTP in order to perform profile mode launching. They are listed under the comment /* INTERNAL API USAGE: BEGINS
Thanks Eugene. As I suspected, you have a very limited/contained set of requirements. We will set you up with nice APIs in the next little while.
Created attachment 50343 [details] Patch for TPTP Eugene/Ali, This is a patch which you will need to apply to the org.eclipse.hyades.trace.ui plug-in once you upgrade to Eclipse 3.2M2 It makes your code a lot simpler, particular the launch shortcuts.
The patch also removes all your dependencies on PDE/UI internals. Two remaining issues will not be addressed here: 1. MainTypeSelectionDialog: We copy this class from JDT/Debug. So if you want it API, then you ask them to make it API. Otherwise, keep your own copy of it like PDE does. 2. SWTLaunchConfiguration: As I mentioned before, SWT/JDT keep wanting to remove the launcher and come up with an alternative (bug 122527). Therefore, PDE will not examine the API status of SWTLaunchConfiguration until that bug is resolved one way or another.
close bug.
