I have seen posts that one can create a “node with nothing in it” except jar files for a shared library node. I assume it needs at least enough in it to be discoverable and loadable - ie: manifest, xml file xxxPlugin.class etc. I would assume similar to the “number formatter” sample except without any code for dialogs, caches, data, ui views, etc etc?
Is there a sample of such a minimum “library” node?
Can the wizard create one?
If so which “Node Type” should I select?
If I need to custom code such a node it how should I go about it?
It would never be needed to instantiate directly in a workflow only be a dependency of other nodes, or have it in the NodeRepository menu
I’m not entirely clear what you mean. I think when you say KNIME node with nothing in it you actually are referring to an Eclipse RCP plugin that doesn’t have any node’s defined in it?
You would then depend on this plugin from other plugins that do define nodes? This way you’d be able to provide your libraries once and an OSGi plugin and have them accessible from multiple different plugins which provide functionality to knime?
but you don’t need to worry about UI contributions.
This would be an example of a plugin which provides jar files (not osgi dependencies) and exposes the classes within an OSGi dependency that can be used by other plugins to write knime nodes:
Yes a proper interpretation - the “nothing in it” came from a StackOverflow post that was vague.
Yes I want to create an entity in our build which when put in the “dropins” folder of a knime installation (or otherwise deployed to it) can be specified as a dependency of our knime plugins to provide a set of shared jar files/classes.
And being a relative noob am trying to find a howto or docs on what to do, and a working sample is always great. I assume since knime and it’s plugins are based on equinox.p2 osgi dependency-bundle manager an appropriate p2 bundle (Eclipse plugin?) is what is needed for shared classes. It needs no other Eclipse GUI functionality, though as our progect matures will likely want to pull in other oss bundles to our plugins as well.
Thanks will check out the links.
Well did so - but a bit ia f learning curve boggle.
It is indeed a plugin in you want then and you can use built in wizards for this assuming you are using an eclipse RCP IDE. An executive summary of the Vogella link:
You can then add your libraries and add them to the classpath section on the Runtime tab on the MANIFEST.MF.
If your dependencies (well the dependencies of the libraries you want to integrate) are available as OSGi dependencies already then it’s best to depend on them this way rather than provide a new instance. You want to avoid providing something that’s already available (logging, xerces…) as this can cause problems for other KNIME plugins.
For reference this is what the runtime config looks like for the plugin I’ve linked to above:
I basically want to relatively quickly get to a build for a minimum shell for a discoverable bundle (discoverable plugin jar file) that I can put our utility jar files or classes into, and then specify it as a dependency of our knime plugins as a place to start, this so they will be injected into the runtime classpath of our plugins.
I will check out the wizard and then see what it generates and put that into our build
Yes on p2 site but for development our non-eclipse build does build->deploy->debug and for development the dropins folder is the most simple and convenient and only dependent on the path to the knime installation…
totally right why I want to put our stuff in a shared model to start with so as later to make it available.
The only issue I might have now is we use Log4j and I need to find a osgi version of it to import otherwise I’ll have to go through some sort of logger wrapper which I have been procrastinating doing. Alas log4j Logger is not specified as an interface!
It is indeed a plugin in you want then and you can use built in wizards for this assuming you are using an eclipse RCP IDE. An executive summary of the Vogella link:
