Community
Participate
Working Groups
It seems to me that if a project references a nature that doesn't exist, no error/warning is shown in the problem view. Usually, a missing nature will end with a reduced usability, and is something user should be aware of. Also, if we want to start introducing quick fixes to detect what to install for a missing nature, having a problem report is a prerequisite. Bug 178135 also tells about it, but it's not clear whereas such markers were actually implemented. In my case, it seems like not.
New Gerrit change created: https://git.eclipse.org/r/68662
New Gerrit change created: https://git.eclipse.org/r/68661
The only change to consider is https://git.eclipse.org/r/#/c/68662/ , the other one is a mistake. Here is the user story I have in mind that makes this feature useful: a user imports an Eclipse project containing an unknown nature (for example an Android one), then user sees the missing nature. As part of the marketplace client, once this problem is reported, there would be a quickfix for this problem to suggest to install ADT (or other) for marketplace to provision this nature. Then user installs, restarts and can work just by following error reports and quickfix without having to read some documentation.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=105372#c38 . Note that the version that is currently on master of org.eclipse.e4.ui repo does NOT require multiple container: a container provider (such as m2e) can add the necessary attributes on the resolved classpath entries when provisioning the container.
@Szymon: Seems like I need your help ;) I've implemented a solution for this issue and wrote a test for it: https://git.eclipse.org/r/#/c/68662/2/tests/org.eclipse.core.tests.resources/src/org/eclipse/core/tests/resources/NatureTest.java . However, it's working locally on my machine, but failing on the CI server, on line 403 (checking the natureId attribute). I conclude (probably wrongly) fromt this difference from a machine to another that it seems to be a matter of synchronization. Are the marker attribute set asynchronously rather than on marker creation? Do you know if there is some instruction that could make sure all pending marker actions are "flushed"?
Do you think there is a chance that it can be considered by M7, so we could then rely on some discovery to implement quick0fix for missing natures.
(In reply to Mickael Istria from comment #5) > @Szymon: Seems like I need your help ;) > I've implemented a solution for this issue and wrote a test for it: > https://git.eclipse.org/r/#/c/68662/2/tests/org.eclipse.core.tests.resources/ > src/org/eclipse/core/tests/resources/NatureTest.java . However, it's working > locally on my machine, but failing on the CI server, on line 403 (checking > the natureId attribute). I conclude (probably wrongly) fromt this difference > from a machine to another that it seems to be a matter of synchronization. > Are the marker attribute set asynchronously rather than on marker creation? > Do you know if there is some instruction that could make sure all pending > marker actions are "flushed"? We need to find out why it behaves in a different way rather than add more calls without knowing the root cause of the difference. Sorry, I didn't have a chance to look at it yet so I can't provide more guidance at the moment. (In reply to Mickael Istria from comment #6) > Do you think there is a chance that it can be considered by M7, so we could > then rely on some discovery to implement quick0fix for missing natures. Bug 178135 that you mentioned in comment 0 is very similar so we should start by finding out what was done in that bug and why the marker is not there but should have been there after that bug was closed. It seems that only finding the right commit in git can tell us that.
(In reply to Szymon Ptaszkiewicz from comment #7) > Bug 178135 that you mentioned in comment 0 is very similar so we should > start by finding out what was done in that bug and why the marker is not > there but should have been there after that bug was closed. It seems that > only finding the right commit in git can tell us that. AS far as I understood about this work done for this bug and it's dual one bug 178131, it just seems like the logging was removed, but an error marker wasn't introduced. Maybe Konstantin can tell more?
> Maybe Konstantin can tell more? Bug 178131 was primarily about this condition resulting in an error log output. Ideally, it should be a problem marker, but our issue was addressed when the error log output was removed and we did not pursue this further.
Thanks Konstantin. @Szymon: then it seems like the change I suggested is still relevant. About the markers attribute being set or not apparently on synchronization issues, could it be that the addition of markers need to be part of a Workspace job?
I guess there is now no chance that this feature gets part of 4.6... Too bad.
(In reply to Mickael Istria from comment #11) > I guess there is now no chance that this feature gets part of 4.6... Correct. I have thought about it during the weekend and adding a new marker can be done only if we will not produce more errors or warnings for existing projects whose users/developers may be happy with the fact they have some missing natures. This means we will probably need a UI part of the fix which will allow to configure the severity of the marker while the default severity will not be too confusing. The info severity seems appropriate. Also, the scope of the new preference needs to be properly chosen whether this should be a project-specific preference or a workspace-specific preference, or maybe something else. There are too many open questions that need to be clarified before it can be merged to have sufficient confidence we will not produce more harm than good and 4.6 is too soon for that.
The only thing that matters from my POV is that users can access related quickfixes easily. I would vote for Warning rather than Info, as a missing nature means that the project will not behave as the person who contributed the .project recommends it, and because it is visible in project explorer. A missing nature is more an issue in the current IDE missing some plugins, not really an issue within the project, so the preference to control the severity would rather be in the workspace IMO. Since I still want to deliver this valuable feature to JBoss Tools users before June 2017, I'll probably put an implementation in the org.eclipse.e4.ui incubator repository, that JBoss Tools and others will be free to consume for their user satisfaction. Too bad the Eclipse Platform schedule encourages forking over contribution for such case.
New Gerrit change created: https://git.eclipse.org/r/71369
Gerrit change https://git.eclipse.org/r/71369 was merged to [master]. Commit: http://git.eclipse.org/c/e4/org.eclipse.e4.ui.git/commit/?id=83bf93390d6c8bc9345bac5a39056d7691a7e2d1
The suggested patch for eclipse.platform.resources was updated to use a warning instead of an error, and makes the test work reliably. This feature is currently cloned and available for immediate usage in http://download.eclipse.org/e4/snapshots/org.eclipse.e4.ui/ as the "Naturist" entry.
@Szymon: Tentative to set target to 4.7.M1. Do you think this is doable?
(In reply to Mickael Istria from comment #17) > @Szymon: Tentative to set target to 4.7.M1. Do you think this is doable? We still need the UI part as mentioned in comment 12. The fact that there are some unknown natures does not mean it is a wrong setup as it can be wanted and expected by a user who may want to avoid setting up a potentially complex environment just to modify a single line in some text file inside a random project. Regarding the scope, it should be possible for a project to override the default workspace setting. For workspace, I think warning is sufficient as the default value with ability to change it to error or info. I'm still thinking whether we need a kind of "ignore" value.
(In reply to Szymon Ptaszkiewicz from comment #18) > We still need the UI part as mentioned in comment 12. The fact that there > are some unknown natures does not mean it is a wrong setup as it can be > wanted and expected by a user who may want to avoid setting up a potentially > complex environment just to modify a single line in some text file inside a > random project. Showing a warning doesn't prevent user from modifying text file, and a warning would IMO not be perceived as something blocker for users. I've been more aware of people unhappy of their IDE because they're missing support for some nature and the IDE not giving them any hint than of the user story you mention. Anyway. At the moment, the Eclipse IDE doesn't present any UI/project page to deal with natures. For the workspace preferences, I suggest to add a combo to select severity in the General > Workspace preference page. For project preferences, I'm thinking about either sdding this same combo to the "Resources" page or to the "Builders" page. Do you have some other suggestion? On the long run, Eclipse IDE is definitely missing ways to deal with natures and should present a dedicated page for projects natures, which could be use to "host" the severity setting, but this is the topic of bug 102527 (for which there is a patch and a dedicated plugin in the e4 sandbox).
(In reply to Mickael Istria from comment #19) > Anyway. At the moment, the Eclipse IDE doesn't present any UI/project page > to deal with natures. I think there are some good reasons to keep it like that. Discussion in bug 102527 is an example. > For the workspace preferences, I suggest to add a combo to select severity > in the General > Workspace preference page. +1. > For project preferences, I'm thinking about either sdding this same combo to > the "Resources" page or to the "Builders" page. > Do you have some other suggestion? "Resources" should be good for now.
Ok. I'll work on a patch for the UI part. I'll amend the current patch to support the preference and consume its value, and I'll make a patch in Platform UI to show this in the dialogs.
(In reply to Mickael Istria from comment #21) > Ok. I'll work on a patch for the UI part. I'll amend the current patch to > support the preference and consume its value, and I'll make a patch in > Platform UI to show this in the dialogs. Thanks!
I'm working on more important/interesting things right now and cannot commit to it for M1. So I've changed the target milestone. However, if anyone else is interested in helping on this feature by adding the necessary preference and consuming it, that'd be highly welcome!
@Szymon: I'm starting to think about implementing the preference. Do you believe a single workspace preference in the InstanceScope to control the severity of all issues of that kind is fine and enough; or do you think it also needs to be specified by project?
(In reply to Mickael Istria from comment #24) > @Szymon: I'm starting to think about implementing the preference. Do you > believe a single workspace preference in the InstanceScope to control the > severity of all issues of that kind is fine and enough; or do you think it > also needs to be specified by project? As mentioned in comment 18, I think we should allow projects to override the workspace default value.
Delayed. Any help regarding Szymon's request would be welcome asI'm not sure I'll hove opportunity to work on it for M4.
(In reply to Szymon Ptaszkiewicz from comment #25) > As mentioned in comment 18, I think we should allow projects to override the > workspace default value. On 2nd thought, I'm not sure about it. Wouldn't it make more sense to configure it on the workspace scope? Would it make sense to have a 1st iteration with a workspace preference (off by default)?
To break the circular dependency with UI, I did a small change on the patch: The new version of the patch set puts a severity of -1/ignore by default. So this change wouldn't be perceived until we have the UI part ready to handle the preference to set severity. So this change is standalone, allows to work on the UI part and doesn't introduce new warnings. Then, once UI part is done, we can consider changing the default severity level to INFO or WARNING. Would this approach work for Eclipse 4.7 ?
Definetely good approach for 4.8. Mickael, let's finish this one and please open a bug for the ui part which either you or Lucas should do.
Gerrit change https://git.eclipse.org/r/68662 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=c264a4fdcdd891ecb21ffc4e13ed1c125ba9f91d
(In reply to Eclipse Genie from comment #30) > Gerrit change https://git.eclipse.org/r/68662 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/ > ?id=c264a4fdcdd891ecb21ffc4e13ed1c125ba9f91d Waiting for the UI part now :).
(In reply to Eclipse Genie from comment #30) > Gerrit change https://git.eclipse.org/r/68662 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/ > ?id=c264a4fdcdd891ecb21ffc4e13ed1c125ba9f91d This causes API warning, new API was added: org.eclipse.core.resources.ResourcesPlugin.PREF_MISSING_NATURE_MARKER_SEVERITY. Please increment minor version segment for org.eclipse.core.resources.
Thanks Andrey, there was a version change in this patch initially, but as it's old it was lost during the rebases. I'm on it right now.
New Gerrit change created: https://git.eclipse.org/r/104752
Gerrit change https://git.eclipse.org/r/104752 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=08805a0911aaf47b8607eac52ce7c9f945578ad6
New Gerrit change created: https://git.eclipse.org/r/105482
New Gerrit change created: https://git.eclipse.org/r/105488
Tentative for 4.8.M3. The 2 last Gerrit reviews allow the feature to be enabled and configured via Preferences.
Gerrit change https://git.eclipse.org/r/105488 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=4b318354f50916c32aabe030d7a359ae418c0940
Gerrit change https://git.eclipse.org/r/105482 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=fd424993770a6336843421da9ef385356fb61eac
All patches in. Mickael, should it be closed now?
Thanks Alex. I'd like to keep it open to track the addition to N&N.
Mickael, please write the N&N and resolve the bug.
New Gerrit change created: https://git.eclipse.org/r/110316
Gerrit change https://git.eclipse.org/r/110316 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=28a682bb09df2a690f7d28cb92a784091166d0b1
Filed bug 526820 to polish it.
