https://community.knime.org/download/ch.fmi.knime.plugins.update/), and research groups in our institute are starting to share workflows using nodes from this site. So I figured it might be useful if the nodes can be discovered via NodePit as well. (NB: our nodes are using the ImageJ2 integration of KNIME Image Processing exclusively, in case that matters...)
https://community.knime.org/download/ch.fmi.knime.plugins.update. Our crawler runs nightly, and it gives a success state for this update site this night at 2018-09-27 03:31:35.833Z. Could you double check again if the mentioned nodes might not already be on NodePit? If not, please let me know, then probably we'll have to see if there's an issue with the crawling setup.
@imagejan @gab1one @dietzc @NodePit_twitter I am back from vacation and had some time to look into this issue. Here is what I found out so far:
During a crawl run, we install all available plugins from an update site into a KNIME installation. Once this is done, we go through all installed nodes and only index those that were provided by one of the plugins hosted on the update site –
AbstractRepositoryObject delivers this information via its
getContributingPlugin() method. This ensures, we only map categories/nodes to update sites that initially came from there.
The FMI nodes behave a bit special. Although the nodes are delivered via a plugin on your update site
https://github.com/fmi-faim/fmi-knime-update-site, their contribution plugin is
org.knime.knip.imagej2.core, which is hosted on a dependent update site. The result is as follows: our indexer ignores them because he assumes they are not part of the current update site.
Maybe you can help us to better understand about how you generate the nodes and why their contribution plugin is hosted on another update site. Honestly, we are currently a bit clueless how to handle this and really appreciate your input :-)
org.knime.knip.imagej2.core. I’m also clueless how your crawler could be modified to detect this autogeneration of nodes.
@imagejan Thanks for providing more insights. In the meantime, we dug a bit deeper into the sources of KNIME and the ImageJ2/FMI node. Unfortunately, we currently don't see a way for us to properly index your nodes as we cannot identify the original source plugin – unless we do not install each plugin separately, which will end up in a mess because of potential dependencies.
For us it seems to be more feasible to tackle this issue within KNIME itself. The
DynamicNodeTemplate currently identifies the contributing plugin by identifying the bundle that provides the implementation of the NodeSetFactory. In your case this is
org.knime.knip.imagej2.core. Nevertheless, your
IJNodeSetFactory should be aware of and be able to provide the original contributing plugin, which is
From our point of view, a possible solution is making the DynamicNodeTemplate better configurable by providing the contributing plugin from "outside" and make use of this feature in your
IJNodeSetFactory. I guess a bunch of "dynamic" nodes might benefit from such a modification. Besides, this may also fix the issue with the KNIME-internal suggestion feature. @gab1one Does this make sense? Any chance to get those changes into KNIME?
libgomp1was not installed that seems to be required by the nodes or one of its dependencies. Don't know if users run into this issue at all, but we just wanted to make sure, you are aware of it.