blob: 6338984ded00b31e772ef8611fa5c4777503f88d [file] [log] [blame]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta
http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<title>org.eclipse.wst.command.env.core</title>
<link
rel="stylesheet"
type="text/css"
href="../sources/formate.css">
</head>
<body>
<p class="ueberschrift">Command/Common Tools</p>
<p>The command component contains command infrastructure including the
Environment Command framework and the Dynamic Wizard framework. This
infrastructure is required by the webtooling project, but is not
specific to webtooling per se. We need to harmonize the several existing
command approaches. Components in this subsystem have no dependancies on
other webtooling components and are not specific to web tooling
functionality, but are needed by other web tooling components.The
component lead is Chris Brealey.</p>
<p class="ueberschrift">What Is The Common Component?</p>
<p>Actually, its three components &ndash; wst.common, jst.common,
wst.command</p>
<p><em>&quot;The common components contain plugins that provide generic
functionality that are applicable in several different contexts. Plugins
in the common component should not have dependencies on plugins outside
of the Eclipse base.&rdquo;</em></p>
<p>Some conceptual tests to decide what should go into common&hellip;</p>
<ul>
<li>Is it destined for API ?
<ul>
<li>if it has no API story, its should be moved into a different
component specific to those who need it</li>
</ul>
</li>
<li>Should it ultimately live in base Eclipse ?
<ul>
<li>common is often used as a temporary staging ground for generic
function that will eventually be absorbed into base Eclipse</li>
</ul>
</li>
<li>What are the dependencies?
<ul>
<li>if the function has dependencies on more than base eclipse,
that&rsquo;s a red flag that it might not be &lsquo;common&rsquo;</li>
</ul>
</li>
<li>Is it generic?
<ul>
<li>Is this function generically applicable to multiple domains in
practice (not just theory</li>
</ul>
</li>
</ul>
<p class="ueberschrift">Plugins - Dependencies</p>
<ul>
<li>Eclipse
<ul>
<li>Platform
<ul>
<li>JDT,Resource</li>
</ul>
</li>
<li>JEM
<ul>
<li>Java Model (Reflective EMF Model)</li>
<li>EMF Extensions (Shared by JEM and WTP)
<ul>
<li>Project scoped Resources</li>
<li>RefResource</li>
</ul>
</li>
</ul>
</li>
<li>EMF
<ul>
<li>Primary metamodel framework</li>
<li>EMF.edit</li>
</ul>
</li>
</ul>
</li>
</ul>
<p class="ueberschrift">API - Status</p>
<ul>
<li>Provisional API
<ul>
<li>Flexible Project API</li>
<li>Validation</li>
<li>Data model wizard/commands</li>
<li>Environment framework</li>
<li>Common Navigator</li>
</ul>
</li>
<li>Internal frameworks
<ul>
<li>EMF extensions: base function shared with JEM to be pushed to
EMF</li>
<li>Proposed API is relatively young</li>
</ul>
</li>
</ul>
<p class="ueberschrift">Common - Evolution</p>
<ul>
<li>Existing plugins may migrate to base Eclipse (or other projects)</li>
<ul>
<li>tabbes properities sheet</li>
<li>project navigator</li>
</ul>
<li>Existing plugins may not be 'common' enough
<ul>
<li>in practice function is less 'common' than we initial thought...
who's actually using it?</li>
</ul>
</li>
</ul>
<p>We need to collectively scrutinize the 'common' components to ensure
things lives in the right place</p>
<br>
<br>
</body>
</html>