Since correction of Bug 436645 [1], the Sirius navigator extension is no more dynamic on Neon, I have created Bug 485019 [2] to track the issue on the Sirius side.
On previous Eclipse version (from Juno to Luna), we expect that when our nature is added/removed on a project or when a file become handled by Sirius, the CNF extension becomes "active": the evaluation of the possibleChildren/triggerPoints changes and new contents are added in the tree (loaded file content, ..)
Here is the extension declaration:
<extension point="org.eclipse.ui.navigator.navigatorContent">
<navigatorContent
activeByDefault="true"
appearsBefore="org.eclipse.jdt.java.ui.javaContent"
contentProvider="org.eclipse.sirius.ui.tools.internal.views.common.navigator.SiriusCommonContentProvider"
icon="icons/obj16/SessionResourceFile.gif"
id="org.eclipse.sirius.ui.resource.content.session"
labelProvider="org.eclipse.sirius.ui.tools.internal.views.common.navigator.SiriusCommonLabelProvider"
name="%navigatorContent.siriusContent.name"
priority="high"
providesSaveables="false">
...
<triggerPoints>
<or>
<and>
<instanceof value="org.eclipse.core.resources.IFile"/>
<test
forcePluginActivation="true"
property="org.eclipse.sirius.ui.isFileForSessionTester">
</test>
</and>
<adapt type="org.eclipse.core.resources.IProject" >
<test property="org.eclipse.core.resources.projectNature"
value="org.eclipse.sirius.nature.modelingproject"/>
</adapt>
<and>
<not>
<adapt type="org.eclipse.core.resources.IProject">
<test
property="org.eclipse.core.resources.projectNature"
value="org.eclipse.sirius.nature.modelingproject">
</test>
</adapt>
</not>
<instanceof value="org.eclipse.core.resources.IFile"/>
<test
forcePluginActivation="true"
property="org.eclipse.sirius.ui.isSemanticResourceFileTester">
</test>
</and>
</or>
</triggerPoints>
...
</extension>
Our declaration contains property testers whose evaluation result might change regarding Sirius preferences, state of a file/project, state of internal concepts in Sirius, ...
I wonder if the correction of Bug 436645 might be improved to never put triggerPoints/possibleChildren evaluations in the new caches if they contain property testers or if we have to modify our declaration ?
But our current workaround might be to remove our property testers to always enable our content extension on all IFile and IProject and move the corresponding tests in the getElements()/getChildren()/hasChildren/getParent() methods. This might have consequences on performances compared to the current behavior.
Regards,
Maxime
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=436645
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=485019
[Updated on: Tue, 12 January 2016 04:39] by Moderator
Home