summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorbkolb2007-10-11 14:53:14 (EDT)
committer bkolb2007-10-11 14:53:14 (EDT)
commit9f76a1e56c393e182ec07d7b32611d59d2fded48 (patch)
tree75050a7d4eab9aaf4aca90d46386dc585d16ae56
parentc2a294374824d9d869c708af1d1d3a4b92f3e372 (diff)
downloadorg.eclipse.mwe-9f76a1e56c393e182ec07d7b32611d59d2fded48.zip
org.eclipse.mwe-9f76a1e56c393e182ec07d7b32611d59d2fded48.tar.gz
org.eclipse.mwe-9f76a1e56c393e182ec07d7b32611d59d2fded48.tar.bz2
fixed the classnames
-rw-r--r--plugins/org.eclipse.emf.mwe.ui/schema/adapters.exsd12
-rw-r--r--plugins/org.eclipse.emf.mwe.ui/schema/handlers.exsd12
2 files changed, 12 insertions, 12 deletions
diff --git a/plugins/org.eclipse.emf.mwe.ui/schema/adapters.exsd b/plugins/org.eclipse.emf.mwe.ui/schema/adapters.exsd
index 2657d3e..569496f 100644
--- a/plugins/org.eclipse.emf.mwe.ui/schema/adapters.exsd
+++ b/plugins/org.eclipse.emf.mwe.ui/schema/adapters.exsd
@@ -6,10 +6,10 @@
<meta.schema plugin="org.eclipse.emf.mwe.ui" id="adapters" name="MWE Debugger Adapters"/>
</appInfo>
<documentation>
- A plugin-in implementing an extension for this extension point can provide additional functionality to the openArchitectureWare debugger.&lt;br&gt;
+ A plugin-in implementing an extension for this extension point can provide additional functionality to the MWE debugger.&lt;br&gt;
&lt;br&gt;
Adapters can translate specific behavior of a syntax element into the neutral common format that is required by the debugger. E.g. variable names and content depend in most cases on the concrete application.&lt;br&gt;
-There are two types of adapters: &lt;code&gt;IElementAdapter&lt;/code&gt; and &lt;code&gt;IPluginAdapter&lt;/code&gt;. Normally there should be always one pair of these for each component with debug behavior.
+There are two types of adapters: &lt;code&gt;ElementAdapter&lt;/code&gt; and &lt;code&gt;PluginAdapter&lt;/code&gt;. Normally there should be always one pair of these for each component with debug behavior.
</documentation>
</annotation>
@@ -55,23 +55,23 @@ There are two types of adapters: &lt;code&gt;IElementAdapter&lt;/code&gt; and &l
<attribute name="runtimeClass" type="string" use="required">
<annotation>
<documentation>
- The name of an IElementAdapter implementation. This class will be instantiated in the runtime VM and be registered in the debugger monitor.&lt;br&gt;
+ The name of an ElementAdapter implementation. This class will be instantiated in the runtime VM and be registered in the debugger monitor.&lt;br&gt;
It is responsible to provide component specific information in a neutral way. It creates name and sourcefile information of an element (one &quot;step&quot; or &quot;Unit of work&quot;), provides name and string representation of variables, converts a breakpoint&apos;s resource and line information into the corresponding sytax element.&lt;br&gt;
More functionality can be implemented to support additional user defined handlers.
</documentation>
<appInfo>
- <meta.attribute kind="java" basedOn=":org.eclipse.emf.mwe.core.debug.processing.IElementAdapter"/>
+ <meta.attribute kind="java" basedOn=":org.eclipse.emf.mwe.core.debug.processing.ElementAdapter"/>
</appInfo>
</annotation>
</attribute>
<attribute name="pluginClass" type="string" use="required">
<annotation>
<documentation>
- The name of an IPluginAdapter implementation. This class will be instantiated in the eclipse VM. It is responsible to handle component specific issues on the eclipse side.&lt;br&gt;
+ The name of an PluginAdapter implementation. This class will be instantiated in the eclipse VM. It is responsible to handle component specific issues on the eclipse side.&lt;br&gt;
It can provide the correct editor Id of an element type for source lookup, breakpoint definition (what is a &quot;Unit of work&quot;) and element type specific image that is shown in the Launch view.
</documentation>
<appInfo>
- <meta.attribute kind="java" basedOn=":org.eclipse.emf.mwe.internal.ui.debug.processing.IPluginAdapter"/>
+ <meta.attribute kind="java" basedOn=":org.eclipse.emf.mwe.internal.ui.debug.processing.PluginAdapter"/>
</appInfo>
</annotation>
</attribute>
diff --git a/plugins/org.eclipse.emf.mwe.ui/schema/handlers.exsd b/plugins/org.eclipse.emf.mwe.ui/schema/handlers.exsd
index 7da82b1..54e4075 100644
--- a/plugins/org.eclipse.emf.mwe.ui/schema/handlers.exsd
+++ b/plugins/org.eclipse.emf.mwe.ui/schema/handlers.exsd
@@ -6,9 +6,9 @@
<meta.schema plugin="org.eclipse.emf.mwe.ui" id="handlers" name="Debugger Handlers"/>
</appInfo>
<documentation>
- A plugin-in implementing an extension for this extension point can provide additional functionality to the openArchitectureWare debugger.&lt;br&gt;&lt;br&gt;
+ A plugin-in implementing an extension for this extension point can provide additional functionality to the MWE debugger.&lt;br&gt;&lt;br&gt;
An MWE debugger process is started in an extra Virtual Machine as in Java. The communication between the runtime VM and the Eclipse VM happens via a socket of the localHost.&lt;br&gt;
-There are two types of handlers: &lt;code&gt;IRuntimeHandler&lt;/code&gt; and &lt;code&gt;IPluginHandler&lt;/code&gt;. Normally there should be always a pair of these, that communicate with each other.
+There are two types of handlers: &lt;code&gt;RuntimeHandler&lt;/code&gt; and &lt;code&gt;PluginHandler&lt;/code&gt;. Normally there should be always a pair of these, that communicate with each other.
</documentation>
</annotation>
@@ -54,24 +54,24 @@ There are two types of handlers: &lt;code&gt;IRuntimeHandler&lt;/code&gt; and &l
<attribute name="runtimeClass" type="string">
<annotation>
<documentation>
- The name of an IRuntimeHandler implementation. This class will be instantiated in the runtime VM, that has normally no direct access to the Eclipse session.&lt;br&gt;
+ The name of an RuntimeHandler implementation. This class will be instantiated in the runtime VM, that has normally no direct access to the Eclipse session.&lt;br&gt;
In the &lt;code&gt;init(...)&lt;/code&gt; method it can register itself in the &lt;code&gt;DebugMonitor&lt;/code&gt; and can that way send commands or react to events to/from the monitor.&lt;br&gt;
If the handler must listen for communication events from eclipse it is reasonable to do it in an extra thread. This thread can be started in the &lt;code&gt;startListener()&lt;/code&gt; method.
</documentation>
<appInfo>
- <meta.attribute kind="java" basedOn=":org.eclipse.emf.mwe.internal.core.debug.processing.IRuntimeHandler"/>
+ <meta.attribute kind="java" basedOn=":org.eclipse.emf.mwe.internal.core.debug.processing.RuntimeHandler"/>
</appInfo>
</annotation>
</attribute>
<attribute name="pluginClass" type="string">
<annotation>
<documentation>
- The name of an IPluginHandler implementation. This class will be instantiated in the eclipse VM. It is responsible to handle commands and events on the eclipse side.&lt;br&gt;
+ The name of an PluginHandler implementation. This class will be instantiated in the eclipse VM. It is responsible to handle commands and events on the eclipse side.&lt;br&gt;
It can send commands through the socket to the runtime side and assumes a corresponding runtime handler that reacts on these commands there.&lt;br&gt;
It can also listen for events on the socket that where sent by a corresponding runtime handler and distribute them to the debug element model (through the &lt;code&gt;DebugModelManager&lt;/code&gt;) or to any other class that provides additional functionality to the Eclipse framwork.
</documentation>
<appInfo>
- <meta.attribute kind="java" basedOn=":org.eclipse.emf.mwe.internal.ui.debug.processing.IPluginHandler"/>
+ <meta.attribute kind="java" basedOn=":org.eclipse.emf.mwe.internal.ui.debug.processing.PluginHandler"/>
</appInfo>
</annotation>
</attribute>