Community
Participate
Working Groups
See bug #416399. With Oxygen version, it could be cool to remove it definitively ?
I agree it would be good to mark them for deletion. We need to add @noreference, @noextend and @noimplement w annotation to the generated class / methods. See https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process Olivier, do you know how to do this for the generated classes?
If we remove those classes we have to remove their definitions also from the UIElements.ecore and regenerate the code... The class UIEvents must be partially regenerated (see the comment line 32 about GenTopic).
We first have to mark it for deletion before removing it, see wiki from Comment 1. Do you know how to add the annotations to the generated code?
Don't for get to visualize that they are deprecated in the e4xmi-Editor
I don't know how to add annotations in the EMF generated code. But I think the good way would be : - Remove the Class from the UIElements.ecore - Keep the old generated Input classes and annotate them manually - Regenerate the EMF code (it will not delete the Input classes) I think it would be the good process...
Actually : - MInput has been annotated as deprecated by Lars in August 2015 - MInputPart has been annotated as deprecated, and no implement by Paul Elder in 2013 in the java doc and in 2015 by Lars before interface definition. So could we say that the deprecation has been done for a while and that we can remove them now ? It means : - Remove both EClasses in the model - Remove usage in UIEvents - Remove References in editors if any Do you agree ?
(In reply to Olivier Prouvost from comment #6) > Actually : > > - MInput has been annotated as deprecated by Lars in August 2015 > - MInputPart has been annotated as deprecated, and no implement by Paul > Elder in 2013 in the java doc and in 2015 by Lars before interface > definition. IIRC I did not mark them for deletion. Deprecation is unfortunately not the same as marking it for deletion. I think we have to follow your suggestion from Comment 5. First step is to ask PMC for deletion approval. I do this later in our PMC call.
We discussed this in the PMC. Before approving to mark them for deletion, someone has to investigate how much work needs to be done to do it. Both have over 50 references.
I started to investigate by removing MInput, MInputPart and all methods related to these classes. Nevertheless, there are still some impacts in EPartService where there is still a legacy method : Collection<MInputPart> getInputParts(String inputUri) this method has never been annotated with @deprecated while MInputPart was. Can we remove it anyway or shall we wait still for 2 years ? So in this first commit I will keep the 2 interfaces, remove all implementations and set the getInputParts as deprecated. I will also remove all EMF constants related to INPUT and INPUT_PART and fix a lot of different UI in ui.tools... Impacts are in this 2 projects : (-> There will be 2 reviews to synchronize...) eclipse.platform.ui eclipse.platform.ui.tools
New Gerrit change created: https://git.eclipse.org/r/116811
Collection<MInputPart> getInputParts(String inputUri) can also be marked for deletion.
New Gerrit change created: https://git.eclipse.org/r/116812
Oliver, according to https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process you need to: 1.) Annotate all APIs that are to be removed with @noreference, @noextend and @noimplement where applicable, update deprecation comment. If applicable do the same for API that depends on it. The comment should contain a link to the bug report to allow feedback from API adopters. 2.) Add an entry in the porting guide. Could you update your patches to follow 1.)?
FYI Olivier, I send an email to cross announcing the plan to mark this API for deletion. Thank you for your work here.
Gerrit change https://git.eclipse.org/r/116811 was merged to []. Commit: http://git.eclipse.org/c/platform/eclipse.git/commit/?id=e42201495b5a269ccdd5da3dc3ba1bd895d52169
Gerrit change https://git.eclipse.org/r/116812 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.git/commit/?id=7ca877ed5a9cb79e8c95b40e4d7c18abf6a9d67a
We also need an entry to our migration guide. Let me try to contribute that.
Btw, in the Gerrit change I do not see MInput. Should that also be marked with @noreference?
New Gerrit change created: https://git.eclipse.org/r/117289
MInput is only marked as deprecated and the MInputPart has a coreference annotation. I can add one on MInput
(In reply to Olivier Prouvost from comment #20) > I can add one on MInput +1
New Gerrit change created: https://git.eclipse.org/r/117291
Gerrit change https://git.eclipse.org/r/117289 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=d7a761220bf5d97fadca3441f0586cf456884a7a
Gerrit change https://git.eclipse.org/r/117291 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=a4c94b91423e7cefd004c2884727838cc01f58b7
Especially when touching APIs it is really important to set the API baaseline. Doing so will show you errors. Those need to be filtered with API problem filters.
(In reply to Dani Megert from comment #25) > Especially when touching APIs it is really important to set the API > baaseline. Doing so will show you errors. Those need to be filtered with API > problem filters. Olivier, can you have a look?
I could have a look if I knew how to proceed this ! But I don't know how to manage API base lines sorry.
Olivier, this should explain it:http://www.vogella.com/tutorials/EclipsePlatformDevelopment/article.html#configure-api-baseline Let me know if you still have issues.
(In reply to Lars Vogel from comment #28) > Olivier, this should explain > it:http://www.vogella.com/tutorials/EclipsePlatformDevelopment/article.html#configure-api-baseline > > > Let me know if you still have issues. As baseline you have to use 4.7.2: http://download.eclipse.org/eclipse/downloads/drops4/R-4.7.2-201711300510/
Ok. I set an API Baseline and I have errors... I get 3 quick fixes : * create a commented compatibility problem filter for MInputPart * create a compatibility problem filter for MInputPart * Configure compatibility problem severity.. I guess the first quick fix ask for a Filter name and the second set the default name ... And it produces a .api_filter file that must be committed in the .settings of the project. So I should create the default filter (quick fix 2), for all problems detected and then commit the .api_filter files ? Is that right ?
(In reply to Olivier Prouvost from comment #30) > Ok. I set an API Baseline and I have errors... I get 3 quick fixes : > > * create a commented compatibility problem filter for MInputPart > * create a compatibility problem filter for MInputPart > * Configure compatibility problem severity.. > > I guess the first quick fix ask for a Filter name and the second set the > default name ... And it produces a .api_filter file that must be committed > in the .settings of the project. > > So I should create the default filter (quick fix 2), for all problems > detected and then commit the .api_filter files ? > > Is that right ? I suggest to add a commented filter for everything EXCEPT "The major version should ..." for the MANIFEST. Once you add a API filter for the individual problems, this one should go away. I usually trigger at least twice a rebuild, as the API tooling has a tendency to not update its error markers at save.
New Gerrit change created: https://git.eclipse.org/r/117371
Olivier, I see three warnings: Description Resource Path Location Type Tag '@noreference' is unsupported on a private field BasicPackageImpl.java /org.eclipse.e4.ui.model.workbench/src/org/eclipse/e4/ui/model/application/ui/basic/impl line 4950 Unsupported Tag Problem Tag '@noreference' is unsupported on a private field BasicPackageImpl.java /org.eclipse.e4.ui.model.workbench/src/org/eclipse/e4/ui/model/application/ui/basic/impl line 5035 Unsupported Tag Problem Tag '@noreference' is unsupported on a private field BasicPackageImpl.java /org.eclipse.e4.ui.model.workbench/src/org/eclipse/e4/ui/model/application/ui/basic/impl line 5048 Unsupported Tag Problem Can you remove the annotations for these private fields?
Sure
Gerrit change https://git.eclipse.org/r/117371 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=87a4aa9c2defe2c91460fb3e9c344813a4623ad8
New Gerrit change created: https://git.eclipse.org/r/117373
Gerrit change https://git.eclipse.org/r/117373 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=5b99147b387b1c0a44140bb2b8206053d6c04445
New Gerrit change created: https://git.eclipse.org/r/117411
Gerrit change https://git.eclipse.org/r/117411 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.tools.git/commit/?id=2861fe374c405a04898318bf1a57f03f1c7a78f8
We also need to add the planned deletion of our migration guide.
Mass change, please reset target if you still planning to fix this for 4.11.
(In reply to Lars Vogel from comment #41) > Mass change, please reset target if you still planning to fix this for 4.11. Sorry, just noticed that the entry does exists since a while.
(In reply to Lars Vogel from comment #31) > Once you add a API filter for the individual problems, this one should go > away. I usually trigger at least twice a rebuild, as the API tooling has a > tendency to not update its error markers at save. It looks as if you are hitting the problem that EMF code generation and API tooling are incompatible. See 543621. If you want to reduce your incompatibilities per change you need to eliminate the "not-API" public static ints most of which are not actually needed. Eclipse OCL has some variant templates that achieve this. @noreference is not really appropriate since any EMF model that extends the platform model must reference the FEATURE_COUNT ints. If they are x-friend limited then @noreference is redundant. If they are public API then @noreference is wrong.
It appears that MInput is defined by Input in UIElements.ecore. It has the http://www.eclipse.org/ui/2010/UIModel/application/ui nsURI. Pedantically any change to the model should change the nsURI (the model version). But a change in nsURI breaks everything, necessitating a multi-nsURI loader. Pragmatically evolution is acceptable, since additions do not often break backward compatibility. Deletions/renames are not acceptable. A model API is much stronger than a Java API which applies to calls to the current code in the current code. A model may be written using an older version of the code. Consequently if any attempt is made to load an old workbench.xmi on a new Eclipse, the EMF loading will fail. The default in EMF is akin to a crash, although skilled users can configure a record unknown features facility to absorb now-illegal features. Opening my current workbench.xmi I find tooltip="org.eclipse.e4.ui.model.application.ui.MInput" It therefore appears that MInput is not obsolete for me. I strongly recommend that model elements are NOT deleted, just leave them deprecated until a new nsURI can be tolerated for "e5". If necessary put in some @generated NOT code to log the dead elements to the Error Log.
Es, as by request of the community we do not increase versions for planned deletions. So we will not increase the nsULR for this deletion nor the major bundle version.
I wrote that pedantiaclly you should increase the nsURI, but that pragmatically you can evolve. Deleting model elements really naughty, particularly if they are still in use (by my workbench.xmi).
Hi Ed, Could you explain us how you use your MInput and MInputPart ? I would bet that you are the only one on earth using it :). If we opened this bug 2 years ago to put it as deprecated it is because it is useless, confusing and noisy in the model. Like the MDialog and MWizard (see bug #531054). We followed the Eclipse process to set something deprecated so as to let people migrate to the new version and to limit the usage of the deprecated stuff during 2 years. In addition we removed the MInput choice (bug also MWizard and MDialog) from the model editor and the model fragment editor. So nobody since 2 years can add this kind of objects, unless they use a very old version of the Eclipse 4 runtime. If, unfortunately, some people still use these objects, I would like to know why and how ? The code Migration for MInputPart should be easy by renaming MInputPart to MPart... Even in the runtime code it is not used internally. If we change the nsURI we will break everything and nothing will be compatible with the new API version. All the code will have to be updated and the runtime should be upgraded to 5.0 release. That would be a huge change for a lot of developers that try to use E4. It is may be not a THE pure practice and not like you proceed for all of your important work on the model projects, I agree, but it is a pragmatic choice as nobody should use that for while. If people want to keep MInput in their model, they can, but they will have to use an older runtime. May be another solution would be to regenerate the MInput and MInputPart classes as 'dynamic' EClass so as to keep them available from the factory but not directly with the code. But this choice would let these useless classes in the API and it would be confusing. So for me, I would 'vote' to remove if definitively from the API. PS : you did not mention MDialog and MWizardDialog (see bug #531054) which are concerned also by the deletion... may be you don't use them ?
I have no idea how/if I use them. I'm not sure that I have ever done any e4 as opposed to 3.x UI coding. I just opened my workbench.xmi to check on the nsURI to see if I was looking at the right *.ecore and was astonished to notice the tooltip="org.eclipse.e4.ui.model.application.ui.MInput" My guess is that my workbench.xmi has acquired some magic content as a result of being used on at least 5 milestones per year since Feb 2015. e.g. it has the magic content that causes it to create GIT repository views on startup in the wrong perspective. My workspace has also advanced backwards and forwards across major platform releases.
Could you attach your model in this bug ?
Created attachment 277682 [details] Requested model
Ok, The reference to the MInput is done in the persistedState part of the MApplication. I don't know how you use your application, but if you restart it using the -clearPersistedState argument (no value to set, only this argument), this line <persistedState> will disappear at startup and start with a new cleaned persisted state. Then after exiting the application it would be interesting to check if the 'MInput' reference is still there (as the model is saved on exit, the line should reappear). If not, it was an old value stored with an old version of the runtime.
The "tooltip" seems to persist some "recent" history and so since I had searched my code for "org.eclipse.e4.ui.model.application.ui.MInput" the workspace had the 'problem' text. A few searches later and it goes away. I tried searching my many workspaces for "MInput" and got no hits, but Windows Search is total SH1T these days so that may not mean anything. I tried setting up an Eclipse search, but Eclipse search seems reluctant to look inside .metadata folders.
(In reply to Ed Willink from comment #52) > Eclipse search seems reluctant to look inside .metadata folders. Can you elaborate on this? Steps? Please file a bug report.
I recall someone telling me that Eclipse search was pruned. Obviously it should exclude Java's bin folders and maven's target folders. But where are the preferences that specify this? I tried ensuring that ".xxx" files are shown. Maybe the 100 results filter clicks in stupidly.
(In reply to Ed Willink from comment #54) > I recall someone telling me that Eclipse search was pruned. Obviously it > should exclude Java's bin folders and maven's target folders. But where are > the preferences that specify this? I tried ensuring that ".xxx" files are > shown. Maybe the 100 results filter clicks in stupidly. No, nothing is filtered out of the box, except for the 1000 (not 100) limit. Please ignore "someone" and file a bug report with steps ;-).
(In reply to Dani Megert from comment #55) > No, nothing is filtered out of the box, except for the 1000 (not 100) limit. Note that this is out of the box. Maybe you checked to ignore binary files and/or derived resources.
Ignoring binary/derived resources is very sensibly the default; hence my perception that there is pruning. m2e fails to mark the target tree as derived. Bug 384356 reopened. I was fooled by a perverse search collation order. The same as the Package Explorer so probably too late to report a bug. In Eclipse, "_" before "." before letter although "_" is a pseudo letter and after "." in ASCII. Unusually, Windows is more consistent; "." before "_" before letter. I failed to spot ".metadata" in the middle of a long list of folders.
Is it time to remove all of this definitively ?
(In reply to Olivier Prouvost from comment #58) > Is it time to remove all of this definitively ? June 2020, see https://help.eclipse.org/2019-09/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fporting%2Fremovals.html
Sorry to post on this resolved bug, but it was the closest reference to a problem I'm currently encounter, I'm currently upgrading an application from Neon to Photon and after changing the SDK version getting > Class 'InputPart' is not found or is abstract Is this related to this change? What is the replacement for InputPart? I also want to mention that https://wiki.eclipse.org/Eclipse4/RCP/FAQ still recommends using InputPart > Eclipse 4 instead distinguishes between a Part and an InputPart. > An input part has a URI to provide the input and can also be marked as dirty Also https://wiki.eclipse.org/E4/UI/Modeled_UI#InputPart still mentions InputPart and I don't see any documentation what to use instead... can a simple Part be used (and marked as dirty)?
(In reply to Christoph Laeubrich from comment #60) > Sorry to post on this resolved bug, but it was the closest reference to a > problem I'm currently encounter, I'm currently upgrading an application from > Neon to Photon and after changing the SDK version getting > > > Class 'InputPart' is not found or is abstract > > Is this related to this change? What is the replacement for InputPart? I > also want to mention that https://wiki.eclipse.org/Eclipse4/RCP/FAQ still > recommends using InputPart You can use a Part and its persistedState. See https://www.vogella.com/tutorials/Eclipse4Services/article.html#mpart-and-multiple-editors for the info or an extended example our commercial training at https://learn.vogella.com/courses/details/rich-client-platform (sorry the exercise is not public available). > > Eclipse 4 instead distinguishes between a Part and an InputPart. > > An input part has a URI to provide the input and can also be marked as dirty > > Also https://wiki.eclipse.org/E4/UI/Modeled_UI#InputPart still mentions > InputPart and I don't see any documentation what to use instead... can a > simple Part be used (and marked as dirty)? Yes, see above.
(In reply to Lars Vogel from comment #61) > You can use a Part and its persistedState. Thanks I'll try that, in Neon "setDirty" has only effect if a part is an EditorPart so that the only reason we used that there as we are saving all data to files/database but good to hear that persitedState is also possible. Still wondering if someone has the insight to update the docs as its a little bit confusing.
(In reply to Christoph Laeubrich from comment #62) > (In reply to Lars Vogel from comment #61) > > You can use a Part and its persistedState. > > Thanks I'll try that, in Neon "setDirty" has only effect if a part is an > EditorPart so that the only reason we used that there as we are saving all > data to files/database but good to hear that persitedState is also possible. > > Still wondering if someone has the insight to update the docs as its a > little bit confusing. https://wiki.eclipse.org/E4/UI/Modeled_UI updated
