Community
Participate
Working Groups
When launching an Eclipse application, if the user wants to customize what to include in the launch configuration, they must select individual plug-ins. This can be quite difficult due to the number of plug-ins available. Launch configs could be managed by features.
Are features being improved at all at the core level (via the p2 team)?
(In reply to comment #1) > Are features being improved at all at the core level (via the p2 team)? > Features are going to be an important consideration in 3,6 for p2, but I don't know what improvements, if any, will come of it.
Also, we should consider making this a bit extensible. Some people like to launch via features... some via bundles... some via packages... Some people have also defined things similar to features. For example, the SpringSource people have PARs (http://static.springsource.com/projects/dm-server/1.0.x/programmer-guide/html/ch04.html#architecture-pars) and the spec has a notion of "Bundle-Category" (which is crap, but some people use it) Essentially, it comes down to a mechanism that allows people to group bundles in some fashion.
Discussed feature based launch with Ankur and Curtis. We are proposing the following: * On the Plug-ins tab, add a new option in the drop down called "features and plug-ins selected below" * When the option is selected that tab will display a composite with two panes. The top pane will be a check box table of available workspace and external features. The table will contain *one* entry for each available feature and have a column cell editor to allow the user to choose between workspace and external feature (if available in both the workspace an target platform). * By default, workspace features will be chosen over external features * A second pane (arranged below the features pane) will show what bundles are contained in the feature selected in the top pane (basically a "feature details pane"). We do not intend to support editing in this pane - you get all the bundles in the feature and workpace bundles are chosen over external bundles in the target platform. * Operations (buttons) availabe in the features pane are: - Select All - Deselect All - Add Required Features - Add Required Bundles - Use Workspace Feature - Use External Feature - Restore Defaults * We likely need the operation to "add required bundles" in the event that a selected feature and its required features don't have all bundles required to run. In this case, we'll need to create a fake "group" of bunldes in the features pane called "Required Bundles", and add those bundles here. * The "Use Workspace/Exeternal Feature" buttons would be used to change where a feature originates from - the workspace or external target platform. They would also work for a multi-select scenarios. * This feature would appear on OSGi ad Eclipse Application launch configurations. * We will also add a "filter" text box at the top of the feature pane to allow a subset of the list to be displayed
Additional notes: * Available features are derived from the ExternalFeatureModelManager and the FeatureModelManager. * The launch configuration itself needs to store selected features in addition to selected plug-ins. So if the user moves between plug-in/feature modes, their selection is still maintained. * The launch delegate needs to generate a plug-in/bundle launch list dynamically from the chosen features, as one of the common use cases of feature based launch is to deal with a set of changing bundles within features.
(In reply to comment #4) > The top pane will be a check box table of available workspace and external > features. The table will contain *one* entry for each available feature and > have a column cell editor to allow the user to choose between workspace and > external feature (if available in both the workspace an target platform). We can now have multiple features with same id and different versions (bug #18500). How we manage them? A checkbox saying "Pick only latest version"?
In general, I don't think you can install different versions of a feature at the same time... In a runtime, I would think that only one version could be installed, so we should only allow you to launch one. (I'm not sure the import work in bug 18500 allows mutltiple versions of features to be imported - as feature import is a separate action/wizard). That being said, one could have two projects in the workspace for the same feature. This should be uncommon. To keep it simple, we could choose the newest version in the workspace. However, we'll also need an "Add Bundles" button to selectively add bundles to a launch. For example, select some features to launch and then add a test bundle that is not part of any feature. This will add the selected (bundle(s)) to the "Other" or "Required Bundles" group.
Created attachment 156688 [details] WIP Patch The UI needs a little finishing touches.
In M6 when the launching is working, I'll help with the UI. Integrate it with the FilteredCheckboxTree proposed in bug 300507.
Created attachment 158334 [details] Working Patch Sord order persisted Launching fixed Add required bundles remains
I had to add a dummy attribute to config file to make the tab dirty. The sort order is persisted in preferences and not in config file. Thus, when sort order changes, the tab doesnt gets marked dirty because it looks for changes in config file. I have added an undocumented dummy attribute just to get the 'apply changes'. suggest me any better alternative approach.
(In reply to comment #11) > I had to add a dummy attribute to config file to make the tab dirty. The sort > order is persisted in preferences and not in config file. Thus, when sort order > changes, the tab doesnt gets marked dirty because it looks for changes in > config file. I have added an undocumented dummy attribute just to get the > 'apply changes'. suggest me any better alternative approach. There should be no attribute in the config for this. When the user changes the sort order, simply update the preference immediately. It's not something they should have to "apply" - it's just presentation and has nothing to do with the actual config.
For the UI, there is a new PDE implementation of the FilteredCheckboxTree that would be worth trying to use here.
Created attachment 159172 [details] Working Patch Patch applied in HEAD. UI updated. The Launch is not yet 100% - working on it. Curtis, you may go ahead with FilteredCheckboxTree related changes in meantime.
I've switch the UI over to the FilteredCheckboxTree and make a few tweaks. Found a number of things that should be fixed. I don't plan on working on them right now, but I can probably help with them later. There is one issue that I'm having that I will have to spend more time on this week. The combo boxes for the cell editors keep opening behind the tree. 1) Can't use GRAY/WHITE colors for the backgrounds as the user may be using a high contrast setting. 2) Instead of having 6 maps, there should be a single list of features (possibly a custom object to store resolution/location). 3) I had a few problems with the select all buttons, probably due to the filtering. 4) If the user has not previously turned on feature based launching the default setting should be all features checked. 5) The cell editor combos may need minimum widths set because of the sizing of the controls on the Mac (see AbstractPluginBlock) 6) The counter should be aligned to the bottom of the tree. (I see there is code t try and fix this, but it isn't working correctly). 7) There is some dead space at the bottom of the tree, no idea where it is being created.
(In reply to comment #15) > I've switch the UI over to the FilteredCheckboxTree and make a few tweaks. > Found a number of things that should be fixed. I don't plan on working on them > right now, but I can probably help with them later. I can fix them up. Will seek your help if am stuck. > There is one issue that I'm having that I will have to spend more time on this > week. The combo boxes for the cell editors keep opening behind the tree. OK > 1) Can't use GRAY/WHITE colors for the backgrounds as the user may be using a > high contrast setting. What colors shall be used then? or shall be remove the conditional enabling of combos completely? > 2) Instead of having 6 maps, there should be a single list of features > (possibly a custom object to store resolution/location). Right. I wanted to push in the UI changes fast so that filtered tree can come in sooner. Will fix it now. > 3) I had a few problems with the select all buttons, probably due to the > filtering. Will analyze. didnt notice it. > 4) If the user has not previously turned on feature based launching the default > setting should be all features checked. will fix it > 5) The cell editor combos may need minimum widths set because of the sizing of > the controls on the Mac (see AbstractPluginBlock) will fix it > 6) The counter should be aligned to the bottom of the tree. (I see there is > code t try and fix this, but it isn't working correctly). working on it Shall we have a checkbox to hide source features? not sure how we will identify the source features though. > 7) There is some dead space at the bottom of the tree, no idea where it is > being created. working on it.
(In reply to comment #16) > What colors shall be used then? or shall be remove the conditional enabling of > combos completely? I don't know offhand how we can give cells a disabled look. Will have to look around for an example. > Shall we have a checkbox to hide source features? not sure how we will identify > the source features though. I don't believe there is anything distinct about the source features that would allow them to be identified (except for having source in their names). I don't think this is worth looking into unless it has been explicitly requested.
Created attachment 159601 [details] Patch with changes as described in comment 15 New model structure few GUI cleansing version persistence removed
> 2) Instead of having 6 maps, there should be a single list of features > (possibly a custom object to store resolution/location). Done in attached patch > 3) I had a few problems with the select all buttons, probably due to the > filtering. still cant find any issues with it > 6) The counter should be aligned to the bottom of the tree. (I see there is > code t try and fix this, but it isn't working correctly). not able to get it right > 7) There is some dead space at the bottom of the tree, no idea where it is > being created. dead space is part of tree control. Picasso revealed it.
Comment on attachment 159601 [details] Patch with changes as described in comment 15 Committed a modified version of the patch. Fixed the spacing and column editor problems by correcting the editor parent (was pointing at the composite holding the filtered tree). Also fixed the location of the count. Added some comments and cleanup.
Trying to launch with all features selected results in an AIOOBE. The BundleHelper is assuming there will always be four entries when there may not be. java.lang.ArrayIndexOutOfBoundsException: 3 at org.eclipse.pde.internal.launching.launcher.BundleLauncherHelper.getFeatureMaps(BundleLauncherHelper.java:404) at org.eclipse.pde.internal.launching.launcher.BundleLauncherHelper.getMergedBundleMap(BundleLauncherHelper.java:89) at org.eclipse.pde.launching.EclipseApplicationLaunchConfiguration.preLaunchCheck(EclipseApplicationLaunchConfiguration.java:246) at org.eclipse.pde.launching.AbstractPDELaunchConfiguration.launch(AbstractPDELaunchConfiguration.java:57) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:853) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:702) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:919) at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1122) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
(In reply to comment #21) > Trying to launch with all features selected results in an AIOOBE. The > BundleHelper is assuming there will always be four entries when there may not > be. > That's because BundleLauncherHelper didn't get checked in from the patch.
(In reply to comment #22) > That's because BundleLauncherHelper didn't get checked in from the patch. Still happens after I fixed the missing update to BundleLauncherHelper.
(In reply to comment #23) > (In reply to comment #22) > > That's because BundleLauncherHelper didn't get checked in from the patch. > > Still happens after I fixed the missing update to BundleLauncherHelper. There are few other bugs too. Am working on it. Will check in the fix soon.
Created attachment 159628 [details] fixed launching fixed other ui problems launching is working now
The current code in HEAD doesn't appear to launch. No application service. I checked the config.ini that is written out and the osgi.bundles property is empty. Without the simpleconfigurator being started and included on the osgi.bundles property, we never write out the bundles.info. java.lang.IllegalStateException: Unable to acquire application service. Ensure that the org.eclipse.core.runtime bundle is resolved and started (see config.ini).
Created attachment 159993 [details] Patch to fix launching of legacy launch configs There seem to be problems when launching "legacy" launch configs, i.e. those that were not aware of feature-based launching at their time of creation. In other words basically all launch configs out there ;-) I stumbled across this in the course of a bug with headless launching with Buckminster, which is using the bleeding edge o.e.pde.launching bundle. See http://www.eclipse.org/forums/index.php?t=msg&th=163025&start=0& for background. The attached patch changes the code to assume a "false" default value for the USE_CUSTOM_FEATURES property if no value is given in the launch config. It thus falls back to (legacy) plug-in based launching, which is exactly what you want for legacy launch configs. The patch is applicable to CVS HEAD.
I am proposing that we make one more significant change for M6. I think that having such granular control over where features and plug-ins are coming from is necessary. I think that having a single radio button or checkbox to control whether features come from the workspace (if available) or externally is enough. I think we'll still need to have the plug-in location options as users have the ability to do so on when managing configs using plug-ins. I'll work something up so when Ankur can give his thoughts when he is available.
Created attachment 160923 [details] New UI Patch Patch with new UI
(In reply to comment #28) > I'll work something up so when Ankur can give his thoughts when he is > available. I have attached the patch with these changes. Have a look and let me know if I got it right.
I have a large number of my changes in my workspace, but was unable to get everything in working order last night, didn't want compile errors in the build :) Sorry, I will get them in as soon as I can.
My changes have been committed. Significant changes to the UI, overhaul of the backing model, fixes to how required plug-ins are calculated. Only remaining issue that I see is that org.eclipse.sdk is required to launch the application. However, because it is not a bundle, it doesn't get included in the requirements (or as a required feature). We may have to put in some sort of hack to add it to the list (but it would be affected by what application the user has chosen to launch with).
(In reply to comment #32) > Only remaining issue that I see is that org.eclipse.sdk is required to launch > the application. However, because it is not a bundle, it doesn't get included > in the requirements (or as a required feature). We may have to put in some > sort of hack to add it to the list (but it would be affected by what > application the user has chosen to launch with). What about launching "non-sdk" Eclipse applications? That works currently without the need of "org.eclipse.sdk".
(In reply to comment #33) > What about launching "non-sdk" Eclipse applications? That works currently > without the need of "org.eclipse.sdk". Which is why if we put a hack in to include the sdk feature we'll have to check what application is being run first.
Any interesting thing that comes up with this feature is the "Plug-ins" tab. The "Plug-ins" name isn't really accurate anymore. Should we consider renaming it and if so, what?
(In reply to comment #35) > Any interesting thing that comes up with this feature is the "Plug-ins" tab. > The "Plug-ins" name isn't really accurate anymore. > > Should we consider renaming it and if so, what? Plug-ins is not entirely inaccurate, when you are selecting features you are just selecting groups of plug-ins to launch (and we are even launching required plug-ins). If we do rename it, I would go with something like "Content". Keeping it similar to the target editor.
(In reply to comment #36) > (In reply to comment #35) > If we do rename it, I would go with something like "Content". Keeping it > similar to the target editor. Content seems to be a good word. I opened bug 304851 to explore this a bit more.
Closing as FIXED. We will be testing this further during the milestone test pass.
*** Bug 26165 has been marked as a duplicate of this bug. ***
