Community
Participate
Working Groups
This is the RAP version of this old bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=381535 I think the critical part is this piece of code, which is NOT present in the bundle if (unique) { choiceTableViewer.addFilter (new ViewerFilter() { @Override public boolean select(Viewer viewer, Object parentElement, Object element) { return !values.getChildren().contains(element); } }); } org.eclipse.emf.rap.edit.ui_2.9.0.v20170609-0928.jar
I made extensive changes in https://bugs.eclipse.org/bugs/show_bug.cgi?id=418619 including changes to this class that would likely be good to port to RAP. But that's quite a bit of work...
(In reply to Ed Merks from comment #1) > I made extensive changes in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=418619 including changes to > this class that would likely be good to port to RAP. But that's quite a bit > of work... I hadn't realized that the standard EMF RAP consists of a copy of the original EMF code, is that right? I think this can't be (easily) maintained... wouldn't it be better to factor out common EMF code and use single sourcing techniques for Eclipse and RAP? In EMF Parsley we use import packages in the common plugin and then have an eclipse plugin and a RAP plugin that actually have (only) the required bundles (the former using the standard eclipse bundles, the latter using the corresponding rap bundles). This way we don't have to duplicate code (of course we have two different development workspaces, but with Oomph it's easy ;). The other way would be to have optional required bundles (requiring both standard plugins and rap plugins, both optional), but I guess then it might be trickier to avoid unwanted and conflicting dependencies in the target platform or in the installed products.
The maintenance efforts are certainly challenging, and RAP for me personally is not a high priority. But I'm totally not keen on the idea of having to have multiple workspaces with different target platforms and different projects. I also have a new build in place at https://ci.eclipse.org/emf/ and it does a single pass that builds all projects. Some of the tests were set up to test RAP and UI Platform versions, but I could not get those to run properly with Tycho Surefire which kind of seems to treat all optional bundle dependencies as greedy. So I'll live with the admittedly nasty duplication effort. :-( And keep my development environment and build environment simpler. :-) I'll make a Gerrit commit and if someone can test and verify that these are correct changes, I can merge them.
New Gerrit change created: https://git.eclipse.org/r/116170
Note that I have a new Gerrit job in place too, so the review has a link to the build and that build has an update site you can use for testing.
Maximilian, Is there anyone on your end with available resource who could test changes such as these? To be honest, I have no idea anymore how to test any of this... :-(
Ed, yes, we could test such changes. Just to be sure, we are talking about the changes from the Gerrit Review: https://git.eclipse.org/r/116170 Correct?
Yes, that's the one.
We will take a look.
I tested the changes of https://git.eclipse.org/r/#/c/116170/ and noticed in the following: The org.eclipe.emf.rap.edit.ui’s plugin.xml is missing entries the following entries: _UI_SetValue_action = &Set Value _UI_SetValue_action_tool_tip = Set Value _UI_ValueAndChoices_label = &Value and Choices _UI_DuplicateValue_message = The feature already contains this value The values are copied from org.eclipse.emf.edit.ui. Without adding these, the properties view does not work as it cannot resolve the message keys. The org.eclipe.emf.rap.edit.ui bundle is missing the following images: icons/full/ctool16/Ellipses.gif icons/full/ctool16/EncodedEllipses.gif icons/full/dlcl16/SetPropety.png icons /full/elcl/SetProperty.png They can be copied from the org.eclipse.emf.edit.ui bundle. When running the generated editor as a RAP application, it is not possible to create a new file. This is the case because the RAP version of EditUIUtil is missing the inner class EclipseUtil and therefore cannot resolve EclipseUtil.getURI at runtime [called in EditUIUtil#getURI(IEditorInput editorInput, URIConverter uriConverter)]. To use EclipseUtil in the RAP version of EditUIUtil, EclipseUtil can be copied in most parts. However, some code using IStorageEditorInput and IURIEditorInput needs to be removed because these interfaces do not exist in RAP (only in org.eclipse.ui). After preliminary fixing this and setting up a basic RAP app that uses the generated editor, I tested the following: PropertyDescriptor.CheckBoxCellEditor: Works as expected in both the duo-state as well as the tri-state variant ExtendedComboBoxCellEditor: Tested for a single value string attribute with three pre-defined choices and isChoiceArbitrary == true. Worked as expected: It allowed to select one of the given choices or type in a new one. MultiLineEDataTypeCellEditor: worked as the non-RAP version FeatureEditorDialog: Tested with a multi String attribute with three pre-defined choicess, isChoiceArbitrary == true, and unique == true: - Added choices were removed from the left side and re-added after removing them from the right side. - Adding new values works and adding of duplicates is prohibited with a proper error message (add button is disabled) Also tested with the same attribute non-unique: Adding the same value multiple times works, too, and choices are not removed from the left side. Clicking the remove button when there is no entry on the right side throws an ArrayIndexOutOfBoundsException at org.eclipse.emf.edit.ui.celleditor.FeatureEditorDialog$16.widgetSelected However, this does not impede the dialog's functionality: The exception was only logged on the console but the dialog continued working.
I just realized the bug was still assigned to me. Lucas has provided testing feedback in his last comment.
