Eclipse中的插件间通信 [英] Inter-plugin communication in Eclipse
问题描述
是否可以创建自动发现eachother的Eclipse插件？
我正在开发一组需要在两种主要情况下运行的插件：
- 个人
- 相互协调。
当单独运行时，插件应该正常工作，但是在一致的情况下，他们将共享一些相同的模型内容，其中一个插件应该向用户显示一个其他插件可以共享内容。例如：
Foo Plugin检测到以下
插件，它可以与以下内容共享本体：
[] Bar插件
[] Baz插件
[]不要共享
Eclipse是否提供任何可以促进其他插件自动检测的内部发布/检测方法？
$ b答案应该是通过声明式服务，它结合了eclipse xml扩展和osgi POJO服务的优点。像osgi服务一样隐含动态，但像eclipse扩展一样加载按需。在2006年推出的eclipse3.3中，您将会发现<这个演示文稿的href =http://www.eclipse.org/equinox/documents/eclipsecon2006/Best%20Practices%20for%20Programming%20Eclipse%20and%20OSGi.pdf =nofollow noreferrer。
声明式服务提供了定义对其他服务的引用的选项。也可以指定参考的基数。基数使用两个数字指定，第一个，0或1表示可选性，第二个，1或n表示多重性。
在实践中， DS（声明服务）不容易使用，因为你必须访问BundleContext，意味着跟踪BundleActivator，这不总是容易 ...
如果您需要的是定义某种面向服务的组件模型，本演示应为您提供今天有不同的选择，以及详细说明这些声明服务
发布r creswick与DS有关：
Is it possible to create Eclipse plugins that auto-discover eachother?
I am developing a set of plugins that need to operate in two primary situations:
- individually
- in concert with each other.
When run individually, the plugins should "just work" but when in concert, they will be sharing some of the same model content, and one of the plugins should present the user with a list of other plugins to share content with. eg:
Foo Plugin detected the following plugins it can share ontologies with:
[ ] Bar plugin
[ ] Baz plugin
[ ] Don't share
Does Eclipse offer any internal publication / detection methods that would facilitate this sort of auto-detection of other plugins?
The answer should be through Declarative Service, which combines the advantages of both eclipse xml extensions and osgi POJO services. Something that is implicitly dynamic like osgi services, but loaded "on demand" like eclipse extensions.
Introduced in 2006 for eclipse3.3, you will find those concepts illustrated in this presentation.
Declarative Services gives the option to define reference to other services. It is also possible to specify the cardinality of the reference. The cardinality is specified using two numbers, the first one, 0 or 1, indicates the optionality, the second one, 1 or n, indicates the multiplicity.
In practice, those DS (Declarative Services) are not easy to use, as you have to access the BundleContext, meaning keeping track of the BundleActivator, which is not always easy...
If what you need is to define some sort of Service Oriented Component Model, this presentation should provide you with the different alternatives existing today, as well as detailing those "Declarative Services"
To publish what rcreswick has found in relation with DS:
- Getting Started with OSGi: Introducing Declarative Services
- Getting Started with OSGi: Declarative Services and Dependencies
这篇关于Eclipse中的插件间通信的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
