Community
Participate
Working Groups
Drop Alphabet soup 1.0.0 parent feature only in the feature directory 1) when Dialog opens (new feature found) we cannot configure broken feature 2) when expanding current configuration, receive parsing error 3) IsBroken doesn't show for this feature 4) Unable to update feature
I fixed 3, but it seems to me UI is agressively opening Dialogs... 1) install Alphabet 1.0.0 2) on the file system, remove features/my.alphabet.round.letters_1.0.0 and features/my.alphabet.straight.letters_1.0.0 3) start eclipse #2 and #4 happen when the child of the feature cannot be created. I am wondeirng if we cannot 'eat' the error to be able to at least unconfigure. Even there, I am not sure we will be able to install a new one as we may face the 'imposter feature' where the files will be there, but teh featur eis not recognize. And updating or re-installing will not solve the issue completely. But user will need to manually delete the plugins/features ? no Anyway, can UI confirm they can bhave with Children feature the same way the behave with root feature (i.e mark as dummy feature with featureRef URL and 0.0.0 as version ?) !MESSAGE Error parsing "feature.xml" stream in the feature archive file:c:/oti/source-code/features/my.alphabet.round.letters_1.0.0.jar/.[java.io.FileNotFoundException: c:\oti\source-code\features\my.alphabet.round.letters_1.0.0.jar\feature.xml (The system cannot find the path specified)] !STACK 0 java.io.FileNotFoundException: c:\oti\source-code\features\my.alphabet.round.letters_1.0.0.jar\feature.xml (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:64) at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:69) at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:133) at java.net.URL.openStream(URL.java:798) at org.eclipse.update.internal.core.FeatureExecutableFactory.createFeature(FeatureExecutableFactory.java:43) at org.eclipse.update.core.FeatureReference.createFeature(FeatureReference.java:152) at org.eclipse.update.core.FeatureReference.getFeature(FeatureReference.java:52) at org.eclipse.update.internal.ui.views.ConfigurationView$LocalSiteProvider.addChildFeatures(ConfigurationView.java:292) at org.eclipse.update.internal.ui.views.ConfigurationView$LocalSiteProvider.getRootFeatures(ConfigurationView.java:271) at org.eclipse.update.internal.ui.views.ConfigurationView$LocalSiteProvider.getConfiguredFeatures(ConfigurationView.java:233) at org.eclipse.update.internal.ui.views.ConfigurationView$LocalSiteProvider.getChildren(ConfigurationView.java:205) at org.eclipse.jface.viewers.AbstractTreeViewer.getRawChildren(AbstractTreeViewer.java:571) at org.eclipse.jface.viewers.StructuredViewer.getFilteredChildren(StructuredViewer.java:346) at org.eclipse.jface.viewers.StructuredViewer.getSortedChildren(StructuredViewer.java:447) at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:241) at org.eclipse.jface.viewers.AbstractTreeViewer.handleTreeExpand(AbstractTreeViewer.java:614) at org.eclipse.jface.viewers.AbstractTreeViewer$1.treeExpanded(AbstractTreeViewer.java:626) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:171) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:75) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:841) at org.eclipse.swt.widgets.Tree.wmNotifyChild(Tree.java:1715) at org.eclipse.swt.widgets.Control.WM_NOTIFY(Control.java:3597) at org.eclipse.swt.widgets.Composite.WM_NOTIFY(Composite.java:571) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2702) at org.eclipse.swt.widgets.Display.windowProc(Display.java:1984) at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:1155) at org.eclipse.swt.widgets.Tree.callWindowProc(Tree.java:147) at org.eclipse.swt.widgets.Tree.WM_LBUTTONDOWN(Tree.java:1344) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2685) at org.eclipse.swt.widgets.Display.windowProc(Display.java:1984) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1222) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1287) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1085) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1068) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:739) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:462) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:176) at org.eclipse.core.launcher.Main.run(Main.java:614) at org.eclipse.core.launcher.Main.main(Main.java:451)
I think we need to crisp this one up a bit. I think this should work as follows: (1) we should not be able to configure a broken feature. I am assuming "Dialog" means the delta processing wizard. Broken input should be marked as broken, and the user should not be allowed to select and process the delta. The user should be allowed to delete the broken delta. Since the feature was being detected as a chenge (delta), and we will not allow it tpo be processed ("applied"), the broken feature will remain unconfigured (2) we should be flagging broken features as an error condition to the user, but should not be throwing exceptions that result in log entries. Showing "missing feature" children in the UI (child entries in the tree) seems like a reasonable approach, but not showing them at all and simply having error messages in the "Show status..." box saying we have missing children is OK as well. I'll let you make the call on this one. The only input I have is that ending up with SAX parse errors in the log is not good. (3) sounds like this one is fixed in core (4) user needs to be allowed to update a broken feature. Since the feature is broken (ie. is missing plugins, children), in this specific case we should allow update to a feature with the same version (ie. enable the install/update button if remote version >= local version)
1) agree 2) agree with dejan about Parser stuff.. hum.. Does core need to change something ? 2 bis) What about if a root feature has only one child missing.. I belive we should at least show childrn features that are OK (but I also believe we all knew that) 2 ter) I vote for showing missing features 3) yes 4)agree, I believe throwing error in #2 prevented any update or reinstall
I have tried this scenario with 20020528. * start eclipse and shutdown * drop alphabet soup feature into features (missing plugins, missing children) * start eclipse .... get told I have changes * changes wizard does not let me configure a broken feature ... GOOD * remove delta * open update manager * current configuration does not show the broken feature ... GOOD * click "Show disabled features" * get error dialog saying I could not parse feature.xml for a child .... BAD (the error makes no sense to user, is logged as well) * I click OK on error * the broken feature appears in the view, correctly marked with red X ... GOOD * it has a [+] beside it that does not expand to anything .... I can live with that * when I show status, it tells me it has 1 missing plugin and 2 missing children ... GOOD So the only problem is the damn error dialog. It seems to be triggered when the UI is constructing the nested feature UI node. We should eat the error, and either construct a missing feature node, or just skip it. The parent will be marked with red X anyways.
Created attachment 1111 [details] root feature .jar -> create directory for it in features/ and expand
One more BAD thing .... * start eclipse * update one of its features (I did this with PDE) .... picked the 200205270931 which was the second latest .... update and shutdown * I deleted 2 of the updated plugins from the file system .... the pde docs and source * started eclipse ... feature shows as broken * went to the eclipse update site * if I select the same version, its [Update] is not showing. This is OK if the feature was not broken (because I already have it installed). But since the feature is broken, we should allow the [Update] so the user can fix the feature up So there seem to be 2 problems left (1) the error dialog (prior post) (2) ability to update broken feature to same version (this post)
Specifically, * in searches (one-click, or other), if the base feature is broken, consider target feature with the same version number as one of the result candidates (add to list before sorting and constraint checking) * in feature preview, enable [Update] if the base feature is broken, and the selected feature version is >= (ie. allow ==)
Implemented.
