Support for implicit project natures

[laeubi]

Currently one has to configure natures on a project explicitly so they are persisted in the .project file.

This is very unflexible and has some drawbacks:

1. Natures can be missing and one gets a warning then
2. A required nature for a project might disable functions and the user has to find out why the desired function is not there
3. We need to have code to explicitly enable natures or "convert" projects
4. It requires to retain project files in the SCM

Instead I think we should have some way to implicitly enable a nature on a project (without persisting it) based on the enable we already have for run shortcuts for example:

<enablement>
               <with variable="selection">
                  <count value="1"/>
               	  <iterate>
                      <adapt type="org.eclipse.jdt.core.IJavaElement">
		                <test property="org.eclipse.jdt.core.isInJavaProjectWithNature" value="org.eclipse.pde.PluginNature"/>
		                <test property="org.eclipse.jdt.core.hasTypeOnClasspath" value="junit.framework.Test"/>
		                <test property="org.eclipse.jdt.junit.canLaunchAsJUnit" forcePluginActivation="true"/>
		             </adapt>
		          </iterate>
               </with>
 </enablement>

for example in pde one has the pluginNature that might be enabled when there is a META-INF/MANIFEST.MF file, in fact tycho-pomless is working that way with great success, also m2e nature can be enabled by having a pom.xml, a java nature is probabbly always useful if any *.java file is in the project and so on, for the case that one does NOT want a nature we then can have a syntax like <nature>!org.eclipse.pde.PluginNature</nature> to explicitly disable a nature if desired.

Please note that this will not automatically enable any builders or classpath entries, these will still need to be explicitly set so this will only enable e.g. menu entries or other actions / code to build on the fact that a given nature was detected.

[akurtakov]

This is something we have discussed with @mickaelistria in the past and the overall goal has been to enable actions/commands/etc. without the need for natures at all if a "condition" is met and thus gradually remove the need for them.

[laeubi]

Yes that's what I noticed today, there is an Action but it has enabledWheNature (...) now I need another Action to configure the nature... but what actually is interesting for most actions if the project has a certain shape and checking that for each and every action is to cumbersome.

[mickaelistria]

IIRC, Action themselves are somewhat deprecated in favor of commands+handlers. Maybe actions don't allow to leverage full expression support, and that could be one reason they're deprecated.
If you can use any expression in enabledWhen, then instead of a nature, you can create a new expression with https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fextension-points%2Forg_eclipse_core_expressions_definitions.html to check for project shape. If doing it in XML is too restricted, then you can also use a property tester https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fextension-points%2Forg_eclipse_core_expressions_propertyTesters.html to define your condition with Java.
Once you have defined this factor (which in a 1st iteration can check for nature), then anything that has enabledWhen based on a nature can be replaced with a single activeWhen/reference, which is as cumbersome as directly the nature, it can even be just an indirection.
In your Java code, you can also write the code that evaluate the expression definition for a given context; so instead of checking project.hasNature, you could use MyProjectLayout.match(project) and reuse the same definition as what's used in plugin.xml.

Overall, I don't think we should aim at "implicit" or "dynamic" project natures as it's the opposite of what nature are meant to be, the expression framework does most of the job already. The only valid nowadays case for relying on a nature is if the condition to know whether project matches or not a type is expensive to compute and not possible to re-evaluate often (so the nature definition becomes a type of "cache" of the evaluation value)

[laeubi]

@mickaelistria that sounds interesting in this case I have specifically org.eclipse.pde.internal.ui.correction.java.UnresolvedImportFixProcessor

       <extension
             point="org.eclipse.jdt.ui.classpathFixProcessors">
          <classpathFixProcessor
                class="org.eclipse.pde.internal.ui.correction.java.UnresolvedImportFixProcessor"
                id="org.eclipse.pde.ui.unresolvedImportQuickFixProcessor"
                name="%classpathFixProcessor.unresolvedImport.name">
                <enablement>
                   <with variable="project">
		              <test property="org.eclipse.jdt.core.isInJavaProjectWithNature" value="org.eclipse.pde.PluginNature"/>
                   </with>
                </enablement>
                <overrides id="org.eclipse.jdt.ui.text.correction.DefaultClasspathFixProcessor"/>
                <overrides id="org.eclipse.jdt.junit.JUnitClasspathFixProcessor"/>
                <overrides id="org.eclipse.jdt.ui.text.correction.DefaultModulepathFixProcessor"/>
          </classpathFixProcessor>
       </extension>

Can you probably create a PR as an example on how one would do this in java?

 <enablement>
     <test isInterestingProjectForPDE() />
  </enablement>

were one can check several thing (for demo of course isJavaNature would be sufficent)