Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 351546

Summary: [patch] [launching] Introduce launcher hooks for bundle based launch configurations
Product: [Eclipse Project] PDE Reporter: Holger Staudacher <holger.staudacher>
Component: UIAssignee: PDE-UI-Inbox <pde-ui-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: enhancement    
Priority: P3 CC: ankur_sharma, beyhan.veliev, curtis.windatt.public
Version: 3.7   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard: stalebug
Bug Depends on:    
Bug Blocks: 347087    
Attachments:
Description Flags
launcher hooks patch
none
updated launcher hook patch none

Description Holger Staudacher CLA 2011-07-08 07:21:15 EDT
The Platform gives you the possibility to add new launcher types. This is great because when you are working with different languages and frameworks an adopted launcher helps a lot. But there is one thing in PDE that makes it hard to integrate a launcher into the IDE/PDE.

I talk about two create operations. E.g. when you create a feature or a product you can choose an existing launch configuration that pre fills your feature/product. This is great because a developer only wants to create a list of bundles once. The bad thing about this is, that this works only with OSGi and Eclipse Launch configurations. When you take a look in the code you always find something like this:

			// if it is an Eclipse launch
			if (id.equals(EclipseLaunchShortcut.CONFIGURATION_TYPE))
				models = BundleLauncherHelper.getMergedBundles(fLaunchConfig, false);
			// else if it is an OSGi launch
			else if (id.equals(IPDELauncherConstants.OSGI_CONFIGURATION_TYPE))
				models = BundleLauncherHelper.getMergedBundles(fLaunchConfig, true);
				
At the RAP Team we have a RAP Launcher which works almost like the OSGi launcher. It holds also a list of bundles. A developer has not chance to use this kind of launch configuration to create a feature or a product. He has to create the list of bundles twice. This is very annoying when you have a lot of bundles. So, it would be very useful if we can hook in into this mechanism to be able to create features/products from existing RAP launch configurations. Of course we do not want to make pde depend on RAP. Therefore we came up with a solution that makes it possible to hook in via an extension.

A colleague of mine will attach a patch that contains this functionality and tests for it. It would be very nice if this can be included into PDE for 3.8. 

Thanks in advance.

Cheers Holger
Comment 1 Beyhan Veliev CLA 2011-07-08 08:42:08 EDT
Created attachment 199329 [details]
launcher hooks patch

Attached patch provides following features:
* defines an extension point which can be used to hook launcher types for feature/product creation.
* extends PDE UI to use this extension point.
* defines extensions for the OSGI and the Eclipse launcher too hook them.
* provides tests
Comment 2 Ankur Sharma CLA 2011-07-08 08:46:45 EDT
Sounds reasonable to me. However, I am not sure when we will have enough
bandwidth for the review. Also, we need to see if it can go in 3.8. May be 4.2
would be better idea.
Comment 3 Holger Staudacher CLA 2011-07-08 08:52:42 EDT
Hi Ankur,
thanks for commenting. Thats why we wanted to provide this patch as early as possible after Indigo. Anyway, let us know if we can help with this.

Thanks in advance.
Comment 4 Ankur Sharma CLA 2011-07-08 09:09:17 EDT
Thank you for the patch. I will try to review it as early as possible. However, expect some delay as we are currently busy with Git migration and planning work.
Comment 5 Curtis Windatt CLA 2011-07-11 16:10:44 EDT
The limitation and the proposed solution are both reasonable.  Looking at the patch, I see that the extension point needs its metadata filled in (description/example).  More importantly, I think we need to change the name of the extension point and classes.  'Launcher hook' doesn't give a developer any idea what you are providing.

BundleListProvider, LauncherBundles, LaunchBundleList

I also noticed the following pattern:
boolean isOsgiLaunchConfigurationType = LauncherHookUtil.isOsgiLaunchConfigurationType(id);
models = BundleLauncherHelper.getMergedBundles(fLaunchConfig, isOsgiLaunchConfigurationType);

The separate call to the launch hook util seems necessary.  I would have expected a single call into BundleLauncherHelper would return the appropriate list or null if the configuration did not have a bundle list.  A new method could also be added to provide the list of all configurations that can provide a list of bundles rather than having the details of the extension used in PluginListPage.java.

I was expecting an API to be defined for the launch configuration to provide the list of bundles (IBundleListProvider.getBundles()), but in the patch the implementation is hidden inside the helper/util classes.  I'm not sure if this is the right approach.  A new API would allow a defined way to access the expected list of bundles a launch would use, but I'm not certain if providing that would be beneficial to the community or limit future launch configuration changes.
Comment 6 Holger Staudacher CLA 2011-07-12 10:27:51 EDT
Hi Curtis,
thanks for your feedback. We will try to rework the patch within this week and attach it again. 

Cheers Holger
Comment 7 Beyhan Veliev CLA 2011-07-16 05:02:50 EDT
Created attachment 199780 [details]
updated launcher hook patch

Attached patch is updated based on the feedback in #comment 2
Comment 8 Beyhan Veliev CLA 2011-07-16 05:22:59 EDT
(In reply to comment #5)

Hi Curtis,

thank you for the fast feedback. See my comments below.

> The limitation and the proposed solution are both reasonable.  Looking at the
> patch, I see that the extension point needs its metadata filled in
> (description/example).  More importantly, I think we need to change the name of
> the extension point and classes.  'Launcher hook' doesn't give a developer any
> idea what you are providing.
> 
> BundleListProvider, LauncherBundles, LaunchBundleList
> 

I updated the extension point's metada. I took the nanme "launchBundleList" for it and renamed the related classes.

> I also noticed the following pattern:
> boolean isOsgiLaunchConfigurationType =
> LauncherHookUtil.isOsgiLaunchConfigurationType(id);
> models = BundleLauncherHelper.getMergedBundles(fLaunchConfig,
> isOsgiLaunchConfigurationType);
> 
> The separate call to the launch hook util seems necessary.  I would have
> expected a single call into BundleLauncherHelper would return the appropriate
> list or null if the configuration did not have a bundle list.  A new method
> could also be added to provide the list of all configurations that can provide
> a list of bundles rather than having the details of the extension used in
> PluginListPage.java.

I extended the "BundleLauncherHelper" with the suggested new methods. For this I also moved the extension point definition into bundle "o.e.pde.launching".

> I was expecting an API to be defined for the launch configuration to provide
> the list of bundles (IBundleListProvider.getBundles()), but in the patch the
> implementation is hidden inside the helper/util classes.  I'm not sure if this
> is the right approach.  A new API would allow a defined way to access the
> expected list of bundles a launch would use, but I'm not certain if providing
> that would be beneficial to the community or limit future launch configuration
> changes.

Our intention for this bug was to provide a possibility to register launch configurations for feature and product creation operations. I think we need to open another bug in case PDE wants to provide new APIs to get the bundle list of a launch configuration. May be it will be enough to provide "BundleLauncherHelper" as API.
Comment 9 Curtis Windatt CLA 2012-03-01 15:40:28 EST
I did a more indepth review and now do not feel confident putting this in for 3.8.

As I mentioned before, the provided API is not complete.  For a client to use this extension point, they must have a launch configuration type that uses all of the same attributes as the PDE ones.  While the attribute ids are public in IPDELauncherConstants, there is no central place describing when and how they are used.  There needs to be a cleaner way to access this information.

Adding the extension point fixes what I see as a very small issue while making it harder for pde launching to change things in the future.

A compromise would be for the extension point to provide a Bundle list factory (or have the launch config adapt to the factory).  The bundle list factory would take a launch configuration as input and return a list of plug-ins or features that configuration includes (perhaps using NameVersionDescriptor).
Comment 10 Lars Vogel CLA 2019-11-14 03:22:51 EST
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

If the bug is still relevant, please remove the "stalebug" whiteboard tag.