Skip to content
Snippets Groups Projects
Commit 88f3f28f authored by david_williams's avatar david_williams
Browse files

removing incorrect files, and adding milestone plan

parent 59d5f112
No related branches found
No related tags found
No related merge requests found
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 9 additions and 9557 deletions
jst/WTPArchAndDesignDocs/.project deleted 100644 → 0
+ 0
− 39
View file @ 59d5f112
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>WTP ArchAndDesign</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
<buildCommand>
<name>com.ibm.etools.webtools.additions.linksbuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>com.ibm.etools.webpage.template.templatebuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>com.ibm.etools.siteedit.SiteNavBuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>com.ibm.etools.siteedit.SiteUpdateBuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>com.ibm.etools.validation.validationbuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>com.ibm.etools.j2ee.StaticWebNature</nature>
<nature>com.ibm.etools.webpage.template.templatenature</nature>
<nature>com.ibm.etools.siteedit.WebSiteNature</nature>
</natures>
</projectDescription>
jst/WTPArchAndDesignDocs/.serverPreference deleted 100644 → 0
+ 0
− 5
View file @ 59d5f112
<?xml version="1.0" encoding="UTF-8"?>
<server-preference>
<deployable factoryId="com.ibm.etools.webtools.server.static"
memento="WTP" server="/Servers/defaultServer.sw"/>
</server-preference>
jst/WTPArchAndDesignDocs/.websettings deleted 100644 → 0
+ 0
− 17
View file @ 59d5f112
<?xml version="1.0" encoding="UTF-8"?>
<websettings version="500">
<project-type>STATIC</project-type>
<webcontent>WebContent</webcontent>
<features>
<feature>
<feature-id>templatefeature</feature-id>
</feature>
<feature>
<feature-id>WebProjectCSSFileFeature</feature-id>
</feature>
<feature>
<feature-id>com.ibm.etools.siteedit.wizards.projectfeature.WebSiteFeature</feature-id>
</feature>
</features>
<context-root>WTP</context-root>
</websettings>
jst/WTPArchAndDesignDocs/.website-config deleted 100644 → 0
+ 0
− 4
View file @ 59d5f112
<?xml version="1.0" encoding="UTF-8"?>
<website version="510">
<structure/>
</website>
jst/WTPArchAndDesignDocs/WebContent/arch_and_design/ArchitectureOverview.html deleted 100644 → 0
+ 0
− 266
View file @ 59d5f112
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<meta name="GENERATOR" content="IBM Software Development Platform" />
<title>Eclipse Webtools Architecture Overview</title>
</head>
<body>
<div align="center">
<table border="1" cellpadding="10" height="50%" width="70%">
<tbody>
<tr align="left" valign="middle">
<td valign="middle" align="left">
<blockquote style="">
<p><cite>The background and status of this document:</cite></p>
<p><cite>This version is a second draft of WTP Architecture Overview
and has incorporated comments received. Comments to wtp-dev list are welcome. </cite></p>
<p><cite> Version 0.3 December 2, 2004. </cite></p>
</blockquote>
</td>
</tr>
</tbody>
</table>
</div>
<h1>Eclipse Webtools Architecture Overview</h1>
<p>The <a href="http://www.eclipse.org/webtools/main.html">Web Tooling
Platform (WTP) Project</a> is made up of two subprojects, <a
href="http://www.eclipse.org/webtools/wst/main.xml">Web Standard Tools
(WST)</a> and <a href="http://www.eclipse.org/webtools/jst/main.xml">J2EE
Standard Tools (JST)</a>.</p>
<p>The <a href="http://www.eclipse.org/webtools/wst/components.xml">list
of components for WST</a> and the<a
href="http://www.eclipse.org/webtools/jst/components.xml"> list of
components for JST</a> give descriptions of the components and
[eventually will contain] links to that component's specific design
documents.
<p>This document describes the <b>subsystems</b> that these components
form. These divisions into subsystems are important because they form
the basis of what is available to other projects, and end-user update
manager features, and features for maintenance streams. Also, it allows
a high level description of internal and external dependancies.</p>
<p>For end-users, there is currently only one news group, <a
href="news:org.eclipse.dev/eclipse.webtools">eclipse.webtools</a>. For
developers, there are currently three mailing lists <a
href="mailto:wtp-dev@eclipse.org">wtp-dev</a>, <a
href="mailto:wtp-wst-dev@eclipse.org">wtp-wst-dev</a>, and <a
href="mailto:wtp-jst-dev@eclipse.org">wtp-jst-dev</a>. As the project
continues, if traffic seems "heavy" for a particular component, then new
mailing lists and/or news groups will be created as needed.</p>
<p>This document decribes the <a href="#subsystemview">Subsystem View</a>, <a
href="#eclipsedependancies">Dependancies on the Eclipse Project</a>, <a
href="#toolsdependancies">Dependancies on Tools Projects</a>, <a
href="#relationtootherprojects">Relation to other Projects and Products</a>, <a
href="#graphicalsummary">Summary in Graphical form</a>, and <a
href="#deployrmentview">Deployment View</a>.</p>
<h1><a name="subsystemview">Subsystem View</a></h1>
<h2>WST Project</h2>
<h3>Build and Test Subsystem</h3>
<p>For completeness, I'll mention our build and test component, highly
modeled after the base Eclipse build and test components.</p>
<ul>
<li>org.eclipse.wtp.releng</li>
</ul>
<h3>Common Subsystem</h3>
<p>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.
<ul>
<li>Common Component
<ul>
<li>Extensible Navigator</li>
<li>Tabbed Property View</li>
<li>Snippets View</li>
<li>Extensible URI Resolver</li>
</ul>
</li>
<li>Validation Framework Component</li>
<li>Command Framework Component</li>
</ul>
<h3>Server Subsystem</h3>
<ul>
<li>Server Component</li>
<li>Internet Component</li>
</ul>
<h3>Database Subsystem</h3>
<p>Will be an update manager feature.</p>
<ul>
<li>RDB/SQL</li>
</ul>
<h3>XML Subsystem</h3>
<p>Will be an update manager feature.</p>
<ul>
<li>XML Component</li>
<li>Schema Component</li>
<li>DTD Component</li>
<li>SSE Component</li>
</ul>
<h3>Web Services Subsystem</h3>
<ul>
<li>WS Component</li>
<li>WSDL Component</li>
<li>WSI Component</li>
</ul>
<h3>Web Resources Subsystem</h3>
<ul>
<li>HTML Component</li>
<li>CSS Component</li>
<li>JavaScript Component</li>
</ul>
<h3>Generic Web Module Subsystem</h3>
<ul>
<li>Web Component</li>
</ul>
<h2>JST Project</h2>
<h3>Server Subsystem</h3>
<ul>
<li>Server Component</li>
</ul>
<h3>JSP Resources Subsystem</h3>
<p>Will be an update manager feature.</p>
<ul>
<li>JSP Component</li>
</ul>
<h3>Basic J2EE Subsystem</h3>
<ul>
<li>Servlet Component</li>
<li>J2EE Component</li>
</ul>
<h3>Advanced J2EE Subsystem</h3>
<ul>
<li>EJB Component</li>
<li>WS Component</li>
</ul>
<h1><a name="eclipsedependancies">Dependancies on the Eclipse Project</a></h1>
<h2>Platform</h2>
<p>All components pervasively required by both WST and JST. Note, there
might be a few not required in short term, such as debug component, but
long term it is easily imagined to be needed.</p>
<h2>JDT</h2>
<p>Not required by WST, but required by JST. Note: we don't rule out
that we might require it someday in WST ... but no known cases
currently.</p>
<h2>PDE</h2>
<p>Not required, though obviously want to verify co-existence.</p>
<h2>WebDav</h2>
<p>While not an official platform project or component, we do want to
verify co-existence.</p>
<h1><a name="toolsdependancies">Dependancies on Tools Projects</a></h1>
<p>In addition to the base Eclipse, the following projects/packages are
prerequisites of the Webtooling Platform. GEF, EMF, and XSD are
pre-req'd by enough of WST to say its always required. The JEM package
is only pre-req'd by JST.</p>
<h2>EMF</h2>
<p>EMF, <a href="http://www.eclipse.org/emf/" target="_top">Eclipse
Modeling Framework</a>, is a way to define meta models, and then
instantiate specific instances of those models. Its particularly famous
for being useful to maintain models across multiple products, especially
when the model may change from one release to another (the way that
deployment descriptors and J2EE specs change from version to version.</p>
<h2>XSD</h2>
<p>The <a href="http://www.eclipse.org/xsd/" target="_top">XSD, XML
Schema Infoset Model, Project</a> provides a model and API for querying
detailed information about schemas and manipulating them. [Note:
technically XSD Infoset is part of Technology Project, but is
distributed with EMF]</p>
<h2>GEF</h2>
<p>GEF, <a href="http://www.eclipse.org/gef/" target="_top">Graphical
Editing Framework</a>, is a framework &quot;on top&quot; of SWT that
makes it easier to develop sophisticated, highly customizable user
interfaces that go beyond typical widgets .</p>
<h2>JEM Package</h2>
<p>The JEM package, Java EMF Model, is actually part of the <a
href="http://www.eclipse.org/vep/" target="_top">VE Project</a>. The VE
team has recently made it available as separate download from their <a
href="http://download.eclipse.org/tools/ve/downloads/drops/S-1.0M2-200407301410/index.html"
target="_top">VE build pages</a>. In addition to allowing easier
interaction with other EMF models, it also incorporates BeanInfo into
its models (not just reflection). We use it in connection to our J2EE
EMF-based models. From what I hear, there's no ISV documentation for
this package, but the rose models that are used to create the meta model
can be found in CVS on dev.eclipse.org<br />
/home/tools<br />
under<br />
/org.eclipse.jem/rose<br />
To load into rose (from workspace) you'd also have to have
org.eclipse.emf.ecore in workspace, and define, in Rose, an EditPathMap
of WorkspaceRoot as what ever your workspace root is on your filesystem
(then it can find included files/models automatically).</p>
<h2>Others</h2>
<p><b>Xerces</b>. We currently ship Xerxes binaries within plugin's
runtimes that require them. [There's been some discussion that with OSGI
classloading of PPS (Platform (bootloader), Pre-reqs, Self), that it
should be easier to provide a common Xerxes plugin, as long as there's
no version requirements conflicts, and no custom class loaders involved,
and appropriate factories used to &quot;get&quot; the specific parts of
Xerxes needed that are not part of the platforms runtime].</p>
<h1><a name="relationtootherprojects">Relation to other Projects</a> and Products</h1>
<h2>J2EE Servers</h2>
<ul>
<li>Apache Tomcat</li>
<li>JBoss</li>
<li>(Jonas)b </li>
</ul>
<h2>Database Servers</h2>
<ul>
<li>Derby (Cloudscape)</li>
<li>With adapters for other products as well, db2.iseries, db2.luw, db2.zseries, informix, oracle, sqlserver, sybase</li>
</ul>
<h1><a name="graphicalsummary">Summary in Graphical form</a></h1>
<p>The following diagrams summarize the subsystem and relationships
described above.</p>
<p></p>
<p><img src="images/wstandjstdependancies.png" width="867" height="454"
border="2" /></p>
<p><br />
The darker shaded subsystems are accessible by end-users and other
components via update manager.</p>
<p><img src="images/wstsubsystems.png" width="606" height="450"
border="2" /></p>
<p><br />The darker shaded subsystem (orange) is accessible by end-users and other
components via update manager.
<br />The white subsytems indicate the &quot;links&quot; into the WST subsystem. The JDT and JEM components indicate two <br />components from other projects required in JST, but not required in WST.
</p>
<h1><img src="images/jstsubsystems.png" width="769" height="475"
border="2" /><a name="deployrmentview"><br />
Deployment View</a></h1>
<p>This section makes explicit what is currently planned to be made available as deployable features via update manager. This is paritally driven by views expressed by community users, and partially dirven by the expressed needs of other projects. It may not be the perfect &quot;slice and dice&quot; of the whole package that would suit everyone, but the expecation is that other projects can always download more than they need, and pick and choose the exact components they want to re-distribute.</p>
<p>All deployment features below will have a &quot;binary&quot; runtime
version, and an SDK version, with all source and developer
documentation. </p>
<p>At the hightest level, is JST and WST seperately. (With JST requireing
WST). </p>
<p>Within JST, user's can choose all of JST, or JSP Subsystem. </p>
<p>Within WST, users's can choose all of WST, or the XML Subsystem
(includes Schema and DTD components), or the Data Subsystem </p>
<p>Of Course, at any point of a decision, the choosen &quot;subcomponent&quot; will still &quot;pull allong&quot; all that its dependent on. </p>
<p></p>
</body>
</html>
jst/WTPArchAndDesignDocs/WebContent/arch_and_design/images/ModelEditing.png deleted 100644 → 0
+ 0
− 0
View file @ 59d5f112
jst/WTPArchAndDesignDocs/WebContent/arch_and_design/images/ModelEditing.png

4.29 KiB

jst/WTPArchAndDesignDocs/WebContent/arch_and_design/images/jstsubsystems.png deleted 100644 → 0
+ 0
− 0
View file @ 59d5f112
jst/WTPArchAndDesignDocs/WebContent/arch_and_design/images/jstsubsystems.png

7.89 KiB

jst/WTPArchAndDesignDocs/WebContent/arch_and_design/images/modelToModel.png deleted 100644 → 0
+ 0
− 0
View file @ 59d5f112
jst/WTPArchAndDesignDocs/WebContent/arch_and_design/images/modelToModel.png

6.02 KiB

jst/WTPArchAndDesignDocs/WebContent/arch_and_design/images/server.png deleted 100644 → 0
+ 0
− 0
View file @ 59d5f112
jst/WTPArchAndDesignDocs/WebContent/arch_and_design/images/server.png

3.54 KiB

jst/WTPArchAndDesignDocs/WebContent/arch_and_design/images/wstsubsystems.png deleted 100644 → 0
+ 0
− 0
View file @ 59d5f112
jst/WTPArchAndDesignDocs/WebContent/arch_and_design/images/wstsubsystems.png

5.95 KiB

jst/WTPArchAndDesignDocs/WebContent/arch_and_design/theme/default_style.css deleted 100644 → 0
+ 0
− 18
View file @ 59d5f112
p, table, td, th { font-family: arial, helvetica, geneva; font-size: 10pt}
pre { font-family: "Courier New", Courier, mono; font-size: 10pt}
h2 { font-family: arial, helvetica, geneva; font-size: 18pt; font-weight: bold ; line-height: 14px}
code { font-family: "Courier New", Courier, mono; font-size: 10pt}
sup { font-family: arial,helvetica,geneva; font-size: 10px}
h3 { font-family: arial, helvetica, geneva; font-size: 14pt; font-weight: bold}
li { font-family: arial, helvetica, geneva; font-size: 10pt}
h1 { font-family: arial, helvetica, geneva; font-size: 28px; font-weight: bold}
body { font-family: arial, helvetica, geneva; font-size: 10pt; clip: rect( ); margin-top: 5mm; margin-left: 3mm}
.indextop { font-size: x-large;; font-family: Verdana, Arial, Helvetica, sans-serif; font-weight: bold}
.indexsub { font-size: xx-small;; font-family: Arial, Helvetica, sans-serif; color: #8080FF}
a.bar:link { text-decoration: none; color: #FFFFFF}
a.bar:visited { color: #FFFFFF; text-decoration: none}
a.bar:hover { color: #FFFFFF; text-decoration: underline}
a.bar { color: #FFFFFF}
.jump { font-size: smaller;; font-family: Arial, Helvetica, sans-serif; color: #8080FF ; font-style: normal; text-decoration: none}
.jump:link { font-size: smaller;; font-family: Arial, Helvetica, sans-serif; color: #8080FF; text-decoration: none}
.jump:hover { font-size: smaller;; font-family: Arial, Helvetica, sans-serif; color: #0000FF; text-decoration: underline; font-style: normal}
jst/WTPArchAndDesignDocs/WorkingFiles/MiscModel.mdl deleted 100644 → 0
+ 0
− 8468
View file @ 59d5f112
This diff is collapsed.
jst/WTPArchAndDesignDocs/directoryDescription.txt deleted 100644 → 0
+ 0
− 5
View file @ 59d5f112
This directory is to contain files and images related to the
high level architecture and design notes for WTP.
Specific components should have their design docs in their
own directories (so can be versioned, etc.) with their component.
jst/components.xml
+ 9
− 0
View file @ 88f3f28f
...@@ -73,6 +73,15 @@ ...@@ -73,6 +73,15 @@
<p> <p>
The jsp component contains the JSP editor, model, views, The jsp component contains the JSP editor, model, views,
wizards, etc. The component lead is David Williams. wizards, etc. The component lead is David Williams.
<ul>
<!-- <li><a href="components/sse/milestone_plan.xml">Milestone Plan</a></li> -->
<li>
<a
href="../wst/components/sse/Milestone 2 Source Editing Test Plan.xml">
Source Editing Test Plan
</a>
</li>
</ul>
</p> </p>
<h3>servlet</h3> <h3>servlet</h3>
......
jst/development/WTPDevelopmentPractice.html deleted 100644 → 0
+ 0
− 208
View file @ 59d5f112
<!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<meta name="GENERATOR" content="IBM Software Development Platform" />
<link rel="stylesheet" href="http://www.eclipse.org/default_style.css"
type="text/css" />
<title>WTP Development Practices</title>
<!-- David Williams, 10/25/04 (david_williams@us.ibm.com) -->
</head>
<body alink="#ff0000" bgcolor="#ffffff" link="#0000ee" text="#000000"
vlink="#551a8b">
<table border="0" cellpadding="2" cellspacing="5" width="100%">
<tbody>
<tr>
<td width="60%">
<p align="LEFT"><FONT size="6"><B><FONT
face="Verdana, Arial, Helvetica, sans-serif">WTP Development
Practices</FONT></B></FONT><FONT size="1"><FONT
face="Arial, Helvetica, sans-serif"><FONT color="#8080ff"><br />
WTP Development Practices</FONT></FONT></FONT></p>
</td>
<td></td>
<td rowspan="2" width="19%"><img
src="http://www.eclipse.org/images/Idea.jpg" border="0" height="86"
width="120" alt="" /></td>
</tr>
</tbody>
</table>
<p>This document is to describe some guidelines, procedures, and
&quot;best practices&quot; for doing WTP development. In some cases its
simply covers consistency/procedure issues, but also recommends best
practices to help community review and involvement. While all component
teams can have their own practices, if anyone has some good tips or
recommendations, please post to wtp-dev for discussion or suggest that
they be added here.</p>
<h2>Code into CVS</h2>
<p>The component developers should provide the following information to
accompany code checked into CVS. Some of this information will become
part of the components 'development' directory in cvs, or on the
component's WTP website, and should be kept up to date as changes take
place and development progresses. (See <A
href="#webanddevelopmentresources" target="_self">Web and development
resources</A> for guidelines on what goes where).</p>
<ul>
<li>
<p>A brief description of the component. This might be an initial
design document, if it exists, but the actual design document can come
later. This brief description should overview the function provided by
the component, but should also list at least a few API's, extension
points, or other &quot;starting points&quot; for anyone wanting to use
or extend the component. (See
/sse/features/org.eclipse.wst.sse.feature/overview/PluginOverview.html
for example).</p>
</li>
<li>
<p>A brief initial work plan: describing what development tasks are
expected for the next milestone or two (or simply in &quot;future&quot;
if not yet planned for a specific milestone). Specific bugs and feature requests
can be tracked with bugzilla, but this plan should be given as a prose
&quot;overview&quot; or highlights of work that is planned towards
refactoring or making the component &quot;platform quality&quot;. See
sse/development/SSEDevelopmentPlan.html for example). In particular, if there are areas that can be explicity tagged with &quot;HELP WANTED&quot;, that would be good since can help let potenital contributors know what areas </p>
</li>
<li>
<p>Each plugin and build feature should contain a 'description' in the
plugin.xml (or feature.xml) file (there is a description tag for such
purpose).</p>
</li>
<li>
<p>A plan for how the component will be documented: both the
&quot;developers guide&quot; type of information (see Platform Plugin
Developers Guide and JDT Plugin Developers Guide in the base Eclipse
for examples) and also the status and plan for design overviews and
&quot;javadoc&quot; type of information.</p>
</li>
<li>
<p>All copyrights and appropriate license files should be correctly
provided.</p>
</li>
<LI>
<b>CVS Hygiene</b>
</LI>
<ul>
<li>
<p>The team should have a &quot;team project set&quot; in their
'development' directory to make it easy for others to check out what
is needed for that component.</p>
</li>
<li>
<p>A minor consistency point: If there's only one &quot;source
directory&quot; it should be named 'src'.</p>
</li>
<li>
<p>A .cvsignore file should be provided which has at least 'bin' in it
to prevent the check in of .class files -- please do this before bin
is committed to the repository (since you can not ignore after its
there). Typically, other &quot;transient files&quot; (such as a
non-custom build.xml, etc) are also added to this .cvsignore file.</p>
</li>
<li>
<p>The source should be formatted according to some stated standard
(e.g. see /wtp-jst-home/development/format) and appropriate Eclipse
compiler options used (e.g. see
/wtp-jst-home/development/compilersettings) to produce &quot;clean
code&quot; (no unnecessary casts, no unused imports, etc.) Its also
recommended the source originally have 'sorted members'. The intent
here is to have clean, consistent code that makes it easier for others
to do diffs, compares, and supply patches.</p>
</li>
</ul>
</ul>
<h2><A name="webanddevelopmentresources">Web and development resources</A></h2>
<P>By convention, a directory named 'development' should be used in the
component's CVS directory structure. This directory would be a peer with
'features' and 'plugins'. These directories should hold things that may
be useful or relevant not only to the developers of the components, but
others interested in contributing (e.g. project team sets, Rose source
files of designs, etc). Things in these directories are not intended to
be in a build. If they are intended for an SDK build, they would be part
of the plugins directory structure.</P>
<P>[Note: there's some CVS work still needed to map the website to an
area in CVS, so the following paragraph will be expanded after that is
established]</P>
<P>For resources that are to be published or linked on the WTP web site,
there will be an area in CVS that parallels the website, so resources
that are placed there will be periodically copied to the whosoever for
proper serving.</P>
<H2>Streams and Builds</H2>
<H3>Code into a Build</H3>
<UL>
<LI>Code can go into a build before its part of a milestone plan, since
frequent builds are important to stay integrated.</LI>
<LI>The component team must be able to do a &quot;local build&quot; (to
work out major kinks in definitions and pre-reqs).</LI>
<LI>In addition to the code itself being in a build, automated unit
tests should also be submitted for the build process.</LI>
</UL>
<H3>Nightly, Weekly, Milestone Builds</H3>
<BLOCKQUOTE>
<P>Nightly builds will be built from the head stream. Occasional compile
errors or unit tests failures would not be abnormal, but should be fixed
by the next nightly build.</P>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Weekly integration builds will be built from developer tagged
versions. There should never be compile errors or unit tests failures in
an integration build, but if that happens then 1) immediate fixes are
required and 2) the offender must wear a red clown nose for the day :).
Integration builds are expected to be of sufficient quality they can be
used as the target in the development environment, though will have
received little or no testing.</P>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Milestone builds are like weekly integration builds except they get
substantial testing. The expectation is that milestone builds be of
sufficient quality that they can be used to self host development.</P>
</BLOCKQUOTE>
<H3>Streams, Stream, and more Streams</H3>
<BLOCKQUOTE>
<P>Most development should take place in the HEAD stream. However, if a
component knows its making large breaking changes that would cause
clients a lot of churn (such as daily, to avoid breaking nightly
build), they can do the major changes in a branch. The component team
should typically keep everyone informed that major development is
occurring in a branch, and naturally, well coordinate the merge back
into the HEAD stream.</P>
</BLOCKQUOTE>
<H2>Self Assessment</H2>
<p>The following criteria can be useful to self-measure the success of a
milestone or release. Component leads should monitor their progress with
these expectations in mind.</p>
<ul>
<li>Made the date</li>
<li>Promised function complete</li>
<li>Unit tests and performance tests complete and running as
&quot;passed&quot;</li>
<li>Test plan with use cases</li>
<li>Function available one week before milestone for testing</li>
<li>Design and APIs reviewed and issues answered before milestone</li>
<li>Community-users buy-in and/or excitement</li>
<li>Included community contributed code.</li>
<li>All &quot;priority 1&quot; defects resolved and all &quot;severity
1&quot; defects addressed.</li>
</ul>
</body>
</html>
jst/development/compilersettings/CompilerSettings1.gif deleted 100644 → 0
+ 0
− 0
View file @ 59d5f112
jst/development/compilersettings/CompilerSettings1.gif

32.1 KiB

jst/development/compilersettings/CompilerSettings2.gif deleted 100644 → 0
+ 0
− 0
View file @ 59d5f112
jst/development/compilersettings/CompilerSettings2.gif

32.9 KiB

0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment

Copyright © Eclipse Foundation, Inc. All Rights Reserved.     Privacy Policy | Terms of Use | Copyright Agent