Equinox provides support for building and running OSGi based web applications both inside RCP and application server environments. In an OSGi web application use -of the OSGi Http Service replaces the use of web.xml deployment file. The Http Service provides a means to register servlets and resources in a manner +of the OSGi Http Service replaces the use of web.xml deployment file. The Http Service provides a means to register servlets and resources in a manner more consistent with the dynamic environment in Eclipse where bundles can come and go.
diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_components.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_components.htm index 08dea21826e..6bdb077acb2 100644 --- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_components.htm +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_components.htm @@ -29,12 +29,12 @@
If your plug-in has a dependency on the org.eclipse.core.runtime bundle, then it will continue to run unchanged. However, if you would like to minimize the number of dependencies, then you are able to pick only the runtime bundles that you use. Dependencies on the runtime bundles may be declared using -either the Import-Package -or Require-Bundle
+either the Import-Package +or Require-BundleIf you would like to use Import-Package header (rather than Require-Bundle) then you should be aware that the org.eclipse.core.runtime package is split across several bundles. The bundles that export a portion of the split package org.eclipse.core.runtime -use a mandatory +use a mandatory directive. The mandatory directive requires importers to specify additional matching attributes in order to successfully wire to the exported package.
For example, to import only the content of the package provided by diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_model_bundles.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_model_bundles.htm index 86468d8e74b..9c1f197e5f8 100644 --- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_model_bundles.htm +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/runtime_model_bundles.htm @@ -26,7 +26,7 @@
The start portion of the life-cycle is worth particular discussion. We've seen already that information @@ -55,45 +55,45 @@
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 +"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 +BundleContext can also be used to find out about other bundles/plug-ins in the system.
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 and +BundleEvent for more information.
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 +BundleContext should be used for this purpose. The platform registry is now used exclusively for information about extensions and extension points.
-The BundleActivator interface defines +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 +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.
Underneath every plug-in lies an OSGi bundle managed by the framework. -The Bundle is the OSGi unit of modularity. Fundamentally, a +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 +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 +or other BundleActivator implementations to represent the plug-in.
diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/secure_storage_architecture.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/secure_storage_architecture.htm index 9c60de26e91..45635924ef2 100644 --- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/secure_storage_architecture.htm +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/secure_storage_architecture.htm @@ -20,7 +20,7 @@The front end is modeled in a fashion very similar to the -OSGi Preferences Service specification. +OSGi Preferences Service specification. Secure storage is represented as a tree of nodes. Nodes provide context. For instance, a bundle "com.abc" could use the node "abc" under the node "com" under the root node. As in Preference's, the path to such node can be described as "/com/abc".
diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/secure_storage_dev.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/secure_storage_dev.htm index c21c75b6acd..b665f63a4f0 100644 --- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/secure_storage_dev.htm +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/secure_storage_dev.htm @@ -34,7 +34,7 @@The restrictions put on the node names are similar to the
-OSGi Preferences:
+OSGi Preferences:
no double forward slashes, no trailing forward slash. In addition, node names can only contain printable ASCII characters.
If you need to use a string that does not fit those restrictions, the
diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/workbench_cmd_expressions.htm b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/workbench_cmd_expressions.htm
index f484ed09884..7b54acc6eb3 100644
--- a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/workbench_cmd_expressions.htm
+++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/guide/workbench_cmd_expressions.htm
@@ -596,7 +596,7 @@ Property Testers Provided in the Workbench
Test the state of the bundle in the running environment. Use the 'args' attribute to pass in the bundle ID and the 'value' attribute to pass the state as defined in Bundle, e.g. "ACTIVE". +
Test the state of the bundle in the running environment. Use the 'args' attribute to pass in the bundle ID and the 'value' attribute to pass the state as defined in Bundle, e.g. "ACTIVE".