I was trying to create plugins that are interrelated. Meaning I have distinct Object groupings that I want to expose as plugins to the orchestrator. Internally however, there is java code that is common between them. It appears that each plugin is managed with its own classloader internally, which means that these common classes may be constructed via different class loaders, which creates problems when objects intermingle.
It would be really cool to have plugins that can depend on other plugins in such a manner as they would be managed via hierarchical class loaders. In this way I could have a core Plugin A that could be extended via a Plugin B. I could then in the Java script create objects from Plugin B and hand them to objects of Plugin A to further manipulate. Then internally, since Plugin B depends on plugin A, Plugin B's classloader would be a child of plugin A's classloader, making it possible for the Plugin A classes to see all instances of Plugin B objects as created within the context of its Plugin A's class loader.
The particular problem I have is that Plugin A works via annotations and the classes in Plugin B are annotated by classes defined in Plugin A. Unless these annotation instances are loaded via the same classloader, they are not seen as equivalent.
Is there some aspect of the plugin mechanism that I have missed that would support this? Is there any plan that would support this in the future?
Their is no official way to be able to "share" class loader between plug-ins. I think there is no way at all... (but have to check)
If you would like more details on the use case I think I have for this type of plugin relationship, I'd be happy to have a direct discussion with you about it.
I can work aound this by building a single plugin, but it means that for API versioning type reasons I would not have as granular control over upgrade and distribution methods.
If you want to send me an email, it should be great.
For example, being able to access the VI plugin from any other plugins, I think...