Assume there are two plugins P1 and P2 are available in eclipse rcp application.
Both P1 and P2 are built separately by different build process
In my scenario depending on the user's choice only p1, only p2 or both plugins are available in the base product.
I want to exchange the data between Plugin P1 and P2 when both the plugins are available, else the plugins will work with their own data.
Will OSGI declarative services work well in my scenario,
is there any way that i can expose service api's which return json or string from Plugin P1 and P2 can consume it with out depending on it explicitly, I mean, Plugin p2 should only consume it when p1 exists, if not, it should function as normal.
Kindly advice.
Edit: Thanks for you suggestion
I completely agree that having a common plugin will be ideal.
However in our case We have a base product and unfortunately we do not have control over, I mean we can add any plugin to the base repository.
Plugin P1 and P2 are 2 different products which work independently of each other but has data which can be complimented with each other. We like to make an api call from Plugin p2, if the plugin p1 is intalled on the base product and use the data to augument the existing views in p2 else show only p2 data.
I assumed, using declerative services, Plugin P2 can call the api's exposed by plugin P1 using osgi specification api's which are part of eclipse standard plugins without adding any dependency between plugins P1 and P2. Please let me know if there any option achieve this.
Of course, you can have optional dependencies - but my recommendation would be to introduce a P3, for keeping the common data. Make P1 and P2 dependent on that plugin and just retrieve the data unconditionally from the common "storage" plugin.
If you're making P1 dependent on P2 (and vice versa) you'd need to make this dependency optional, and you're introducing a cyclic compile time dependency of both. A great way to resolve such a cycle is to introduce a common third module that just implements the common needs.
Edit: Answering to your comments - if you have P1 register a service that P2 references, then P2 will be dependent on P1 for the service's interface, unless you register a class from a common P3 on which both depend. That being said, nothing keeps you from registering arbitrary JRE classes as a service - this would be unconventional and a weird hack, but I guess you could register a HashMap as a service. It feels unclean, smelly, hacky, and weird - and the maintainers of your code might haunt you, but I guess technically it's possible. Did I say that I am not recommending that and that it's ugly?