Bug 540499 - Provide ability to hide generic "Validate" menu entry contributed in org.eclipse.wst.validation.ui
Summary: Provide ability to hide generic "Validate" menu entry contributed in org.ecli...
Status: RESOLVED FIXED
Alias: None
Product: WTP Common Tools
Classification: WebTools
Component: wst.validation (show other bugs)
Version: 3.11   Edit
Hardware: PC Linux
: P3 enhancement (vote)
Target Milestone: 3.12   Edit
Assignee: Nitin Dahyabhai CLA
QA Contact: Chuck Bridgham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 540709
  Show dependency tree
 
Reported: 2018-10-26 06:12 EDT by Simeon Andreev CLA
Modified: 2019-02-25 16:34 EST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simeon Andreev CLA 2018-10-26 06:12:13 EDT
In order to use the WebTools XML editor in our product, we added the following features to our installation:

org.eclipse.wst.common_core.feature
org.eclipse.wst.xml_core.feature
org.eclipse.wst.xml_userdoc.feature
org.eclipse.wst.common_ui.feature
org.eclipse.wst.xml_ui.feature

We then observe that context menus on files, folders and editors have a "Validation" entry. This seems to be coming from a plug-in required by those features, org.eclipse.wst.validation.ui. This plug-in has the following in its plugin.xml:

   <extension
         point="org.eclipse.ui.popupMenus">
      <objectContribution
            adaptable="true"
            objectClass="org.eclipse.core.resources.IResource"
            id="ValidationMenuAction">
         <action
               label="%VBF_UI_POPUP_RUNVALIDATION"
               class="org.eclipse.wst.validation.internal.ui.ValidationMenuAction"
               menubarPath="additions"
               enablesFor="+"
               id="ValidationAction">
         </action>
      </objectContribution>      
   </extension>

Its unclear what running this action is supposed to do, in that it appears on folders, projects and Java/xtext sources without anything more specific than "validate". 

It would be great if this entry is somehow conditional; it should only appear in cases in which *something* is actually validated. It would also be great if the menu entry or action is a bit more verbose.

We have many validation steps in our product; an unspecific menu entry will only confuse our users.
Comment 1 Simeon Andreev CLA 2018-10-26 06:13:48 EDT
Note that I'm yet to check if this is the only place where the menu item is contributed. There may be others as well.
Comment 2 Andrey Loskutov CLA 2018-10-26 08:47:13 EDT
Ideally:
1) The "Validate" is renamed to "Validate XML" so that user at least have a chance to know *what* is going to be validated here.
2) There is a new preference "Add "Validate XML" context menu to files and folders", which is disabled by default. It really makes no sense to add this unconditionally. We have too many context menus, and contribution this "Validate XML" to IResource means it will appear in each and every possible view / editor working with resources. Just imagine each and every language provider would add "Validate" menus - we would have "Validate CSS", "Validate XSD", "Validate JS", "Validate SQL", etc, all on "hello.txt" file. Nightmare.
3) The menu for single files appears ONLY if they are of XML content type and the preference above is set to "true".
4) The menu for IResource appears only in a global "Source" menu, like "Source -> Validate XML".
Comment 3 Nitin Dahyabhai CLA 2018-10-26 11:31:38 EDT
(In reply to Andrey Loskutov from comment #2)
> Ideally:
> 1) The "Validate" is renamed to "Validate XML" so that user at least have a
> chance to know *what* is going to be validated here.
> 2) ...Just imagine each and every language
> provider would add "Validate" menus - we would have "Validate CSS",
> "Validate XSD", "Validate JS", "Validate SQL", etc, all on "hello.txt" file.
> Nightmare.

You can't have it both ways, and given that the action applies to folders and projects, the current behavior is option 1.
Comment 4 Andrey Loskutov CLA 2018-10-26 12:01:21 EDT
(In reply to Nitin Dahyabhai from comment #3)
> (In reply to Andrey Loskutov from comment #2)
> > Ideally:
> > 1) The "Validate" is renamed to "Validate XML" so that user at least have a
> > chance to know *what* is going to be validated here.
> > 2) ...Just imagine each and every language
> > provider would add "Validate" menus - we would have "Validate CSS",
> > "Validate XSD", "Validate JS", "Validate SQL", etc, all on "hello.txt" file.
> > Nightmare.
> 
> You can't have it both ways, and given that the action applies to folders
> and projects, the current behavior is option 1.

Current behavior is clear, or do you mean the solution would be just rename it? I would disagree.

Most users don't want to have "Validate XML" on their projects, which do not have any XML code to be validated. 

Either we *know* that some project has a "XML" related nature, and menu appears on them, or (like JDT / CDT projects) the context menu is not shown and instead we have something else. Similar for JDT / CDT - they do not add "Compile that" or "Fix nullpointers here" on any projects.

Compromise proposal: there is a "Source" submenu on all resources (at least in Package Explorer). Can we rename "Validate" to "Validate XML" *and move* this to the "Source" submenu?
Comment 5 Simeon Andreev CLA 2018-10-29 06:55:26 EDT
>  Compromise proposal: there is a "Source" submenu on all resources
> (at least in Package Explorer). Can we rename "Validate" to "Validate XML"
> *and move* this to the "Source" submenu?


There are actually 2 Source sub-menus.

One is coming from JDT:

org.eclipse.jdt.ui/plugin.xml:               id="org.eclipse.jdt.ui.source.menu">

The other is coming from WebTools source edit:

core/bundles/org.eclipse.wst.sse.ui/plugin.xml:                 <menu id="sourceMenuId" label="%Source"></menu>

Theoretically we can re-define the validation action to a command and add it to the already defined Source sub-menu of WebTools source editing. However the WebTools common part seems to be what the source edit depends on; not the other way around.

So not sure if we really want this.
Comment 6 Nitin Dahyabhai CLA 2018-10-29 14:55:18 EDT
I think a lot of this is confusion based on having installed *only* the XML features. Also, Validation doesn't modify what is being validated.
Comment 7 Simeon Andreev CLA 2018-10-30 02:40:11 EDT
(In reply to Nitin Dahyabhai from comment #6)
> I think a lot of this is confusion based on having installed *only* the XML
> features. Also, Validation doesn't modify what is being validated.

Sorry, I don't see how this makes sense. We want to add only the XML editor from WebTools, so an extra entry "Validate" appears in all context menus regardless of actual context. If this "Validate" action makes sense only if everything from WebTools is installed, why do we see it when we want only a minor portion of WebTools?
Comment 8 Nitin Dahyabhai CLA 2018-10-31 14:36:42 EDT
(In reply to Simeon Andreev from comment #7)
> (In reply to Nitin Dahyabhai from comment #6)
> > I think a lot of this is confusion based on having installed *only* the XML
> > features. Also, Validation doesn't modify what is being validated.
> 
> Sorry, I don't see how this makes sense. We want to add only the XML editor
> from WebTools, so an extra entry "Validate" appears in all context menus
> regardless of actual context. If this "Validate" action makes sense only if
> everything from WebTools is installed, why do we see it when we want only a
> minor portion of WebTools?

The Validation Framework is extensible. Other parts of WTP, and adopters, also plug into it to offer validation of other file types and projects. The Validate action, which is contributed from the framework, triggers all of the ones that are installed and applicable. It does not "only" makes sense if everything from WTP is installed.
Comment 9 Andrey Loskutov CLA 2018-10-31 15:14:55 EDT
So the Validation should be moved to Source -> Validation (or any other more suitable location NOT in the top level menu), if it not only validates XML. It has really nothing to do on the root level, especially if it is that generic that it can do everything and so can't have a concrete name.

Or, like it was before, it could be shown only in a dedicated perspective or only for dedicated editors (extending sse for example).
Comment 10 Nitin Dahyabhai CLA 2018-10-31 17:16:36 EDT
Validation doesn't modify file contents. It doesn't belong in a Source menu. I'm not sure when "before" is referring to.
Comment 11 Andrey Loskutov CLA 2018-10-31 17:51:55 EDT
(In reply to Nitin Dahyabhai from comment #10)
> Validation doesn't modify file contents. It doesn't belong in a Source menu.

Why not? The only reason to "validate" something is to check if the "source" is correct (whatever it is). If "validate" does something useful, the next logical action will be to "fix" the found issue in the source.

But if not source, which other sub menu makes more sense?

> I'm not sure when "before" is referring to.

Linked bug 112269.
Comment 12 Andrey Loskutov CLA 2018-10-31 17:59:48 EDT
Another way to deal with this "Validate" contribution: can we define "Webtools" or "Web Validation" activity and link this menu to it? One could then disable this activity via product customization. I think all products which include XML editor only would greatly benefit from that. One of the biggest Eclipse problems is the ever increasing UI complexity, which gets worse woth every additional plug in added to it.
Comment 13 Eclipse Genie CLA 2018-11-01 10:48:20 EDT
New Gerrit change created: https://git.eclipse.org/r/131803
Comment 15 Eclipse Genie CLA 2018-11-01 17:14:41 EDT
New Gerrit change created: https://git.eclipse.org/r/131819
Comment 16 Simeon Andreev CLA 2018-11-02 03:05:50 EDT
(In reply to Andrey Loskutov from comment #12)
> Another way to deal with this "Validate" contribution: can we define
> "Webtools" or "Web Validation" activity and link this menu to it? One could
> then disable this activity via product customization.

I'll try this out.
Comment 17 Andrey Loskutov CLA 2018-11-02 03:10:24 EDT
(In reply to Simeon Andreev from comment #16)
> (In reply to Andrey Loskutov from comment #12)
> > Another way to deal with this "Validate" contribution: can we define
> > "Webtools" or "Web Validation" activity and link this menu to it? One could
> > then disable this activity via product customization.
> 
> I'll try this out.

Still, if the activity will be enabled, on the long term plan I would be happy to see Validate not on the root level and definitely not in every editor.
Comment 18 Simeon Andreev CLA 2018-11-02 03:38:57 EDT
(In reply to Andrey Loskutov from comment #17)
> Still, if the activity will be enabled, on the long term plan I would be
> happy to see Validate not on the root level and definitely not in every
> editor.

Probably best to split this into 2 bugs then:

1. Provide a way to hide "Validate" entry. Intended for platform maintainers who want to include only minimal functionality from WebTools (e.g. me and Andrey).
2. Provide a meaningful location and *activation rules* for the "Validate" entry. This will be more work (probably a lot more).
Comment 19 Andrey Loskutov CLA 2018-11-02 03:40:48 EDT
Right.
Comment 20 Simeon Andreev CLA 2018-11-02 06:22:35 EDT
OK, I created bug 540709 for efforts to try and make the "Validate" entry more platform friendly.

As for this ticket, hiding the "Validate" entry, if I combine Andrey's suggestion for an activity and Nitin's suggestion for a property tester with product ID, I can add the following to *our own products xmls*:

diff --git a/opt/93000/src/segments/eclipse/workspace/com.verigy.itee.ui/plugin.xml b/opt/93000/src/segments/eclipse/workspace/com.verigy.itee.ui/plugin.xml
index 196e8ea45a08..1d6ec809f075 100644
--- a/opt/93000/src/segments/eclipse/workspace/com.verigy.itee.ui/plugin.xml
+++ b/opt/93000/src/segments/eclipse/workspace/com.verigy.itee.ui/plugin.xml
@@ -614,4 +614,26 @@
             name="%large.files.text.editor.name">
       </editor>
    </extension>
+
+   <!-- some ticket number: hide the "Validate" entry coming from Web Tools Platform, which we don't need; we only include a XML editor -->
+   <extension
+         point="org.eclipse.ui.activities">
+      <activity
+            name="Web Tools Validation Activity"
+            description="Validating XML, HTML, CSS and so on"
+            id="org.eclipse.wst.validation.ui.ValidationActivity">
+         <enabledWhen>
+            <not>
+               <test property="org.eclipse.core.runtime.product" value="... our own products id..."/>
+            </not>
+         </enabledWhen>
+      </activity>
+   </extension>
+   <extension
+         point="org.eclipse.ui.activities">
+      <activityPatternBinding
+            activityId="org.eclipse.wst.validation.ui.ValidationActivity"
+            pattern="org.eclipse.wst.validation.ui.ValidationAction">
+      </activityPatternBinding>
+   </extension>

Any thoughts Andrey? Should we just close this as "works for me" due to the above?
Comment 21 Andrey Loskutov CLA 2018-11-02 06:28:08 EDT
I'm using XML editor too in my plain nightly SDK builds, and ideally I would like to see this activity/preference already in the Webtools, otherwise I have to write my own plugin just to disable the menu. I guess everyone (and especially product maintainers) would be happy not to maintain extra code just to disable some menus, where one preference/command line option could be enough.

So I think we should ship this with Webtools.
Comment 22 Andrey Loskutov CLA 2018-11-02 06:30:08 EDT
However proposed patch tedts for a product id, while ideally one could just define some system property.
Comment 23 Eclipse Genie CLA 2018-11-02 07:23:03 EDT
New Gerrit change created: https://git.eclipse.org/r/131846
Comment 24 Eclipse Genie CLA 2018-11-05 14:43:02 EST
New Gerrit change created: https://git.eclipse.org/r/131947
Comment 25 Nitin Dahyabhai CLA 2018-11-05 15:01:37 EST
Rebuilding the action as a command, proposed in change 131947, should make it easier to have bug 540709 do something like put it into an action set only enabled by default in WTP's perspectives.
Comment 26 Nitin Dahyabhai CLA 2018-11-12 16:59:12 EST
Committed https://git.eclipse.org/c/webtools-common/webtools.common.git/commit/?id=6a7e67f6a1932db7cbd9a9d7a8b1779e14220c1d . The menu contribution can now be turned off at the product level as well as with a system property.
Comment 27 Simeon Andreev CLA 2018-11-13 02:15:50 EST
Thanks!
Comment 28 Simeon Andreev CLA 2018-12-14 08:06:37 EST
Hi Nitin,

when will the next WebTools build be available?

Best regards and thanks,
Simeon
Comment 29 Nick Boldt CLA 2018-12-14 08:15:17 EST
CI builds are available every time they run:

https://build.eclipse.org/webtools/committers/wtp-R3.12.0-I/

Stable builds arrive here:

https://download.eclipse.org/webtools/downloads/drops/R3.12.0/?d

RC1 is the last build for 3.12, which will become 3.12.0.R.

Hope that helps!
Comment 30 Simeon Andreev CLA 2018-12-14 08:21:58 EST
Thanks a lot!

I was looking at https://download.eclipse.org/webtools/downloads/, didn't realize there were already available builds.