Eclipse插件和OSGI束（Plug-ins and bundles）
The mechanics for supporting plug-ins are implemented using the OSGi framework. From this standpoint, a plug-in is the same thing as an OSGi bundle. The bundle and its associated classes specify and implement the process for Java class-loading, prequisite management, and the bundle's life-cycle. For the rest of this discussion, we use the terms plug-in and bundle interchangeably, unless discussing a particular class in the framework.
插件支持结构是通过OSGI框架实现的，从这个角度来看，一个插件等同于一个OSGI束（bundle）。bundle及其相关的类定义和实现了java类的加载、管理和bundle的生命周期。在后面的讨论中，除非是框架中一个特殊的类，“plug-in”和“bundle”交互使用。
Plugin
The Plugin class represents a plug-in that is running in the platform. It is a convenient place to centralize the life-cycle aspects and overall semantics of a plug-in. A plug-in can implement specialized function for the start and stop aspects of its life-cycle. Each life-cycle method includes a reference to a BundleContext which can supply additional information.
Plugin类描述了一个在平台上运行的插件，这样方便集中插件的生命周期和全部语意的管理。一个插件能够实现插件生命周期开始和结束特殊功能。每个生命周期方法包含一个能够提供额外信息的束上下文（BundleContext）参照。
The start portion of the life-cycle is worth particular discussion. We've seen already that information about a plug-in can be obtained from the plug-in's manifest file without ever running any of the plug-in's code. Typically, some user action in the workbench causes a chain of events that requires the starting of a plug-in. From an implementation point of view, a plug-in is never started until a class contained the in the plug-in needs to be loaded.
插件生命周期的启动部分特别值得讨论。我们可以看到包含在插件的manifest文件中的插件信息，而不需要运行插件的任何代码。通常，工作台中的用户行为触发一连串的事件，而引起插件的启动。通过实现的角度来看，除非插件中的一个类需要加载，插件不会运行。
The start method has been a convenient place to implement initialization and registration behavior for a plug-in. However, it is important to realize that your plug-in can be started in many different circumstances. Something as simple as obtaining an icon to decorate an object can cause one of your plug-in's classes to be loaded, thus starting your plug-in. Over-eager initialization can cause your plug-in's code and data to be loaded long before it is necessary. Therefore, it's important to look closely at your plug-in's initialization tasks and consider alternatives to performing initialization at start-up.
插件的启动方法方便于实现插件的初始化和注册行为。但是，插件可以在许多不同的环境中启动，认识到这一点很重要。获得一个用于修饰对象的图标这样简单的动作都可以导致引起插件类的加载，从而到引起插件的启动。过多的初始化导致插件在需要之前就花费很长时间加载插件的代码和数据。因此，认真检查插件的初始化任务并考虑换一种方法在启动时实现初始化，是非常有意义的。
Registration activities such as registering listeners or starting background threads are appropriate during plug-in start-up if they can be performed quickly. However, it is advisable to trigger these actions as part of accessing the plug-in's data if the registration activities have side-effects such as initializing large data structures or performing unrelated operations.
在插件启动时，如果运行速度很快，可以进行各种注册，例如注册监听器或者启动后台线程。但是，如果注册行为具有副作用，例如初始化大量数据结构或者执行不相关的操作，在访问插件数据时触发注册行为才是更为可取的。
Initialization of data is best done lazily, when the data is first accessed, rather than automatically in the start-up code. This ensures that large data structures are not built until they are truly necessary.
数据的初始化最好是懒加载，在数据第一次使用时加载，而不是在启动代码中加载。这样保证了除非在真正必要的时候大型数据结构不会构建。
Bundle Context
Life-cycle management is where the OSGi "bundle" terminology and the platform's "plug-in" terminology meet. When your plug-in is started, it is given a reference to a BundleContext from which it can obtain information related to the plug-in. The BundleContext can also be used to find out about other bundles/plug-ins in the system.
生命周期管理是术语OSGI “bundle”和平台“plugin”相通的地方。当插件启动时，获得一个BundleContext的参照，通过这个参照可以获得插件相关的信息。BundleContext也可以用于获得系统中其他束/插件。
BundleContext.getBundles() can be used to obtain an array of all bundles in the system. Listeners for BundleEvent can be registered so that your plug-in is aware when another bundle has a change in its life-cycle status. See the javadoc for BundleContext and BundleEvent for more information.
BundleContext.getBundles()可以用于获得系统所有bundle的一个数组。可以注册BundleEvent的监听器(Listeners),从而在另一个bundle在其生命周期状态中发生变化时，你的插件能够得到消息。更多的内容可以查看BundleContext 和 BundleEvent的文档。
Prior to 3.0, a plug-in registry (IPluginRegistry) was provided to supply similar information. For example, it could be queried for the plug-in descriptors of all plug-ins in the system. This registry is now deprecated and BundleContext should be used for this purpose. The platform registry is now used exclusively for information about extensions and extension points.
相对于3.0，插件的注册器(IPluginRegistry)提供类似的信息。例如，可以在系统中查询所有插件的插件描述。这个注册器现在已经撇弃，而使用BundleContext来实现。现在平台上的注册器专门用于注册扩展和扩展点的相关信息。
Bundle Activator
The BundleActivator interface defines the start and stop behavior implemented in Plugin. Although the Plugin class is a convenient place to implement this function, a plug-in developer has complete freedom to implement the interface for BundleActivator in any class appropriate for the plug-in's design. In fact, your plug-in need not implement this interface at all if it does not have specific life-cycle management needs.
BundleActivator接口定义了插件启动和停止运行的行为。尽管这个插件类方便于实现这个功能，插件开发者在任何合适的类中完全可以灵活地实现这个接口。实际上如果插件没有特殊的生命周期的管理的需要的话，插件根本不需要实现这个接口。
Bundles
Underneath every plug-in lies an OSGi bundle managed by the framework. The Bundle is the OSGi unit of modularity. Fundamentally, a bundle is just a collection of files (resources and code) installed in the platform. Each bundle has its own Java class loader, and includes protocol for starting, stopping, and uninstalling itself. From the Eclipse platform point of view, Bundle is merely an implementation class. Plug-in developers do not extend the bundle class, but use Plugin or other BundleActivator implementations to represent the plug-in.
在每一个插件后面都有一个框架的OSGI bundle。Bundle时OSGI模块性单元。从根本上说，一个bundle是一个安装在平台中的文件（资源和代码）的集合。每一个bundle有自己的Java类加载器，并且包括启动、停止和卸载的协议。从Eclipse平台角度来看，Bundle仅仅是一个实现类。插件开发者没有扩展bundle类，但是使用Plugin或者其他BundleActivator实现去描述插件。
2007.06.27(translaition)
插件支持结构是通过OSGI框架实现的，从这个角度来看，一个插件等同于一个OSGI束（bundle）。bundle及其相关的类定义和实现了java类的加载、管理和bundle的生命周期。在后面的讨论中，除非是框架中一个特殊的类，“plug-in”和“bundle”交互使用。
Plugin
The Plugin class represents a plug-in that is running in the platform. It is a convenient place to centralize the life-cycle aspects and overall semantics of a plug-in. A plug-in can implement specialized function for the start and stop aspects of its life-cycle. Each life-cycle method includes a reference to a BundleContext which can supply additional information.
Plugin类描述了一个在平台上运行的插件，这样方便集中插件的生命周期和全部语意的管理。一个插件能够实现插件生命周期开始和结束特殊功能。每个生命周期方法包含一个能够提供额外信息的束上下文（BundleContext）参照。
The start portion of the life-cycle is worth particular discussion. We've seen already that information about a plug-in can be obtained from the plug-in's manifest file without ever running any of the plug-in's code. Typically, some user action in the workbench causes a chain of events that requires the starting of a plug-in. From an implementation point of view, a plug-in is never started until a class contained the in the plug-in needs to be loaded.
插件生命周期的启动部分特别值得讨论。我们可以看到包含在插件的manifest文件中的插件信息，而不需要运行插件的任何代码。通常，工作台中的用户行为触发一连串的事件，而引起插件的启动。通过实现的角度来看，除非插件中的一个类需要加载，插件不会运行。
The start method has been a convenient place to implement initialization and registration behavior for a plug-in. However, it is important to realize that your plug-in can be started in many different circumstances. Something as simple as obtaining an icon to decorate an object can cause one of your plug-in's classes to be loaded, thus starting your plug-in. Over-eager initialization can cause your plug-in's code and data to be loaded long before it is necessary. Therefore, it's important to look closely at your plug-in's initialization tasks and consider alternatives to performing initialization at start-up.
插件的启动方法方便于实现插件的初始化和注册行为。但是，插件可以在许多不同的环境中启动，认识到这一点很重要。获得一个用于修饰对象的图标这样简单的动作都可以导致引起插件类的加载，从而到引起插件的启动。过多的初始化导致插件在需要之前就花费很长时间加载插件的代码和数据。因此，认真检查插件的初始化任务并考虑换一种方法在启动时实现初始化，是非常有意义的。
Registration activities such as registering listeners or starting background threads are appropriate during plug-in start-up if they can be performed quickly. However, it is advisable to trigger these actions as part of accessing the plug-in's data if the registration activities have side-effects such as initializing large data structures or performing unrelated operations.
在插件启动时，如果运行速度很快，可以进行各种注册，例如注册监听器或者启动后台线程。但是，如果注册行为具有副作用，例如初始化大量数据结构或者执行不相关的操作，在访问插件数据时触发注册行为才是更为可取的。
Initialization of data is best done lazily, when the data is first accessed, rather than automatically in the start-up code. This ensures that large data structures are not built until they are truly necessary.
数据的初始化最好是懒加载，在数据第一次使用时加载，而不是在启动代码中加载。这样保证了除非在真正必要的时候大型数据结构不会构建。
Bundle Context
Life-cycle management is where the OSGi "bundle" terminology and the platform's "plug-in" terminology meet. When your plug-in is started, it is given a reference to a BundleContext from which it can obtain information related to the plug-in. The BundleContext can also be used to find out about other bundles/plug-ins in the system.
生命周期管理是术语OSGI “bundle”和平台“plugin”相通的地方。当插件启动时，获得一个BundleContext的参照，通过这个参照可以获得插件相关的信息。BundleContext也可以用于获得系统中其他束/插件。
BundleContext.getBundles() can be used to obtain an array of all bundles in the system. Listeners for BundleEvent can be registered so that your plug-in is aware when another bundle has a change in its life-cycle status. See the javadoc for BundleContext and BundleEvent for more information.
BundleContext.getBundles()可以用于获得系统所有bundle的一个数组。可以注册BundleEvent的监听器(Listeners),从而在另一个bundle在其生命周期状态中发生变化时，你的插件能够得到消息。更多的内容可以查看BundleContext 和 BundleEvent的文档。
Prior to 3.0, a plug-in registry (IPluginRegistry) was provided to supply similar information. For example, it could be queried for the plug-in descriptors of all plug-ins in the system. This registry is now deprecated and BundleContext should be used for this purpose. The platform registry is now used exclusively for information about extensions and extension points.
相对于3.0，插件的注册器(IPluginRegistry)提供类似的信息。例如，可以在系统中查询所有插件的插件描述。这个注册器现在已经撇弃，而使用BundleContext来实现。现在平台上的注册器专门用于注册扩展和扩展点的相关信息。
Bundle Activator
The BundleActivator interface defines the start and stop behavior implemented in Plugin. Although the Plugin class is a convenient place to implement this function, a plug-in developer has complete freedom to implement the interface for BundleActivator in any class appropriate for the plug-in's design. In fact, your plug-in need not implement this interface at all if it does not have specific life-cycle management needs.
BundleActivator接口定义了插件启动和停止运行的行为。尽管这个插件类方便于实现这个功能，插件开发者在任何合适的类中完全可以灵活地实现这个接口。实际上如果插件没有特殊的生命周期的管理的需要的话，插件根本不需要实现这个接口。
Bundles
Underneath every plug-in lies an OSGi bundle managed by the framework. The Bundle is the OSGi unit of modularity. Fundamentally, a bundle is just a collection of files (resources and code) installed in the platform. Each bundle has its own Java class loader, and includes protocol for starting, stopping, and uninstalling itself. From the Eclipse platform point of view, Bundle is merely an implementation class. Plug-in developers do not extend the bundle class, but use Plugin or other BundleActivator implementations to represent the plug-in.
在每一个插件后面都有一个框架的OSGI bundle。Bundle时OSGI模块性单元。从根本上说，一个bundle是一个安装在平台中的文件（资源和代码）的集合。每一个bundle有自己的Java类加载器，并且包括启动、停止和卸载的协议。从Eclipse平台角度来看，Bundle仅仅是一个实现类。插件开发者没有扩展bundle类，但是使用Plugin或者其他BundleActivator实现去描述插件。
2007.06.27(translaition)