Skip to content
Snippets Groups Projects
Commit 71a11a03 authored by ryman's avatar ryman
Browse files

Moved webtools Web site into new CVS repository location

parent 4209efca
Branches
Tags
No related merge requests found
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 1328 additions and 0 deletions
commit.html 0 → 100644
+ 118
− 0
View file @ 71a11a03
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US"><head>
<body bgcolor="#FFFFFF">
<link rel="stylesheet" href="../default_style.css" type="text/css">
<table border=0 cellspacing=5 cellpadding=2 width="100%" >
<tr>
<td align=LEFT valign=TOP colspan="1" bgcolor="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">
Eclipse Webtools Committers by Subproject</font></b></td>
<td align=RIGHT valign=TOP colspan="1" bgcolor="#0080C0"><font face="Arial,Helvetica" color="#FFFFFF">
Thu Nov 11 21:30:02 2004</font></td>
</tr>
</TABLE>
<table border=0 cellspacing=5 cellpadding=2 width="100%" >
<tr bgcolor="#999999">
<td width="75%" align=left valign=top colspan="2"><b><font face="Arial,Helvetica" color="#ffffff"><a name="webtools"></a><a href="../webtools" target="_top" class="bar">Webtools
Subproject</a> </font></b></td>
</tr>
</table>
<table width="75%" border="1"></TABLE>
<table border=0 cellspacing=5 cellpadding=2 width="100%" >
<tr bgcolor="#999999">
<td width="75%" align=left valign=top colspan="2"><b><font face="Arial,Helvetica" color="#ffffff"><a name="wtp"></a><a href="../wtp" target="_top" class="bar">Wtp
Subproject</a> </font></b></td>
</tr>
</table>
<table width="75%" border="1"><tr><td width="30%"><b>Phil Avery</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>Chris Brealey</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>Chuck Bridgham</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>Der_Ping Chou</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>Nitin Dahyabhai</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>Naci Dai</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>Timothy Deboer</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>Gorkem Ercan</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>Bjorn Freeman-Benson</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>Sinan Konya</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>Valeriy Pelyushenko</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>Arthur Ryman</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>Craig Salter</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>Deniz Secilir</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>Sheila Sholars</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>Ozgur Tumer</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
<tr><td width="30%"><b>David Williams</b></td> <td>org.eclipse.wtp.releng<br>wtp-jst-home<br>
wtp-wst-home
<br>
</td></tr>
</TABLE></body></html>
\ No newline at end of file
committers/list.html 0 → 100644
+ 255
− 0
View file @ 71a11a03
<hhtml>
<head>
<link rel="stylesheet" href="http://www.eclipse.org/default_style.css" type="text/css">
</head>
<body bgcolor="#FFFFFF">
<table border=0 cellspacing=5 cellpadding=2 width="100%" >
<tr>
<td align=LEFT valign=TOP colspan="1" bgcolor="#0080C0"><b>
<font face="Arial,Helvetica" color="#FFFFFF">Committer Infrastructure
Requests</font></b></td>
<td align=RIGHT valign=TOP colspan="1" bgcolor="#0080C0">
<font face="Arial,Helvetica" color="#FFFFFF">November 22, 2004</font></td>
</tr>
</TABLE>
<table width="75%" border="1"></TABLE>
<p>This list of Eclipse.org infrastructure requests is being collected from the
committer community by Committer Board Representatives John Wiegand and Bjorn
Freeman-Benson. Please vote on the weighting of these items using <a href="http://www.superboy.org/cgi-bin/eclipse-vote.cgi">our
web form</a>. The votes will be tallied for presentation at the Dec 8th Board
Meeting.</p>
<ol>
<li><b>Project Dashboard/Statistics.</b> Number of bugs, number of new bugs, number
of fixed bugs, downloads, page views, mailing list messages, et.</li>
<li><b>Wikis</b>. Per-project would probably be best. (also see 20)</li>
<li><b>Blogs</b>. Per-project or per-component or per-individual? (also see
20)</li>
<li><b>Hierarchical Blogs.</b> The blogs should be linked hierarchically so
that big news items can bubble up like they do on the SourceForge news system.
The idea is that when someone in, say, VEP publishes a blog entry, John D
(over in Tools) would be notified, and with the click of a button, could
promote the entry to be visible on the Tools project's weblog. And if John D
promotes it, it would then be forwarded to an Eclipse.org content manager who
could then click a button to make it visible as an Eclipse front-page news
item. (also see 20)<ul>
<li>This would subsume an event repository for project-specific “What’s new”. Can be tagged
and queued for the home page.</li>
</ul>
</li>
<li><b>EMO Web Content. </b>In particular, presence (website, wikis, blogs,
mailing lists, cvs, ...) for processes, councils, etc.</li>
<li><b>Reputation System</b>. No community can function without a reputation
system. Online communities with large growth rates are especially vulnerable
because the new members do not have the history that helps them filter the
good from the bad. A reputation system (like E-bay's seller ratings) is
necessary. (also see 21)<ul>
<li>The idea here is to capture the communities trust in specific
individuals in a formal way so that other people can view that trust.
Obviously, committers would have to be in a high trust/high reputation space
in order to be committers. So this is more applicable to non-committers on
the newsgroups and mailing lists.</li>
<li>There have been at least three (one very recently) disruptive individual
on the newsgroups. To a newbie, there is no way to tell whether this vocal
person is knowledgeable or just noisy; whether I, the newbie, should trust
them or ignore them.</li>
<li>The EMF system has a
<a href="http://download.eclipse.org/tools/emf/scripts/models.php">trivial
version of this</a>.</li>
</ul>
</li>
<li><b>Short URLs</b>. Direct (short) URLs to project sections, a.k.a., no
frames. Definitely no frames.</li>
<li><b>Per-project navigation bars.</b> Managed by the project.</li>
<li><b>Proposals Section</b>. A “proposals” section (Eclipse Labs?) to nurture
new proposals instead of hosting them at other companies or at sourceforge.</li>
<li><b>RSS and Atom.</b> For all blogs, wikis, and web pages.</li>
<li><b>Subversion.</b> In addition to CVS</li>
<li><b>Servlets and JSP</b>. For active, rather than static, project web pages.<ul>
<li>Which quite naturally also means MySQL and read/write file-system space
for configuration and/or data files in case a servlet isn't complicated
enough to justify using a database.</li>
</ul>
<li><b>PHP/MySQL.</b> Some projects would prefer to use PHP rather than
servlets and JSP.</li>
<li><b>Central Password Authentication System.</b> Implement a central
password authentication scheme such as ldap for as many services as possible
(download server, Bugzilla, cvs etc). Currently, each user authenticates
against separate password files on each server. </li>
<li><b>
Self Management</b>. Creating new components, managing mailing
lists, adding/removing committers, ..., more sourceforge-like… Use workflow management for IP crucial tasks like
adding new committers (requires EMO
interaction, but parts can be self-managed)<ul>
<li>It sure would be nice if whatever system we use/produce could be
packaged like <a href="http://www.gforge.org">GForge</a>, the software that
ObjectWeb uses, and made available for others who want a collaboration
system like we have built.</li>
<li>Or maybe just work with GForge to build whatever enhancements we need
into their system. We would benefit by having something to start from. They
would benefit from whatever enhancements we build for them...</li>
</ul>
</li>
<li><b>Newer Faster Hardware.</b> Implement new, faster hardware with a
scalable architecture and redundancy for core services. The current
eclipse.org hardware is not sufficient for the for current services provided.
In addition, it is not scalable for increases in traffic. Nor is it highly
available in the in the event of hardware failure. This new hardware needs to
be implemented before additional services can be implemented. This will
improve the performance of several core eclipse.org services such as Bugzilla
and cvs.
<ul>
<li>And more bandwidth. Lags of a minute or more on bugzilla and CVS are
hurting productivity and changing the very nature of the interactions that
have been so successful in creating Eclipse so far.</li>
</ul>
</li>
<li><b>Leverage Mirrors.</b> Leverage the mirrors to reduce bandwidth. (see
also 26)
<ul>
<li>One idea Bjorn had was to limit the bandwidth available to each person
per time unit (suggestions available) and then to charge a nominal fee ($1?)
for an extra download.&nbsp; Use Paypal to clear payments. Structure this to
hit only those who download three copies of the SDK in a single day.</li>
<li>Give the mirrors higher QoS than straight downloads and then encourage
high use clients (companies such as IBM and HP) to have internal mirrors.
IBM already does this.</li>
<li>Automatically redirect users to a geographically close mirror based on
the locale setting in their browser. They can only download from the main
apache site as a last resort. This is what the Apache project
<a href="http://httpd.apache.org/download.cgi">does</a>.</li>
<li>Mirroring of <i>all</i> projects, not just the platform.</li>
</ul>
</li>
<li><b>Additional Sysadmin/Webdev.</b> Acquire additional system administration
resources. Currently, the Eclipse Foundation currently has only one system
administrator to manage all the servers, respond to all user requests and
implement changes. This is a tremendous amount of work for one person. In the
event of illness, vacation or other issues, there isn't anyone to back him up.
Given the importance of these servers to eclipse.org community, this is not a
sufficient allocation of resources. This would also improve response time to
committer requests. (see also 25)<ul>
<li>To quote one of the many committers who voiced this opinion &quot;I've always
found our website to be an embarrassment -- but I've accepted its current
state since I value a kick-ass platform more than a nice website! But it is
time this changes, we don't have a choice. The community is getting too
large and our tooling is getting in the way of our productivity.&quot;</li>
</ul>
</li>
<li><b>Bugzilla.</b> The current bug tracking mechanism/tool imposes lots of
work on the committers doing the bug triage. Given that most of us spent a
noticeable amount of time in Bugzilla there should be improvements to make
committer's live easier.
<ul>
<li>Bugs are often incomplete or duplicates of existing bugs. Other projects
for example have mandatory fields (e.g. the build id) and show a list of
possible related bugs which the bug reporter can check for duplicates before
reporting a new one. </li>
<li>Searching is also a problem since stack traces are often in attachments
which aren't searched. Stack traces are good means to find duplicates.
However stack traces are often attached. So search in attachments must be
supported as well.</li>
<li>Better UI so that bug reporters don't forget to report essential
information (build number, log entries, reproducible steps, ....)</li>
<li>In general Bugzilla should find duplicate candidates and should present
them to the bug reporter before the bug gets committed.</li>
</ul>
</li>
<li><b>Committer Control Over Web Content</b>. Whatever form: blogs, wikis, or
other web content flavour of the month. We just want to be able to create a
page for some current issue or plan item, and be able to create a reasonably
short URL for it. This current issue list is a good example. I had to stick
that list into the webtools project space even though it is unrelated to web
tools. Similarly, the &quot;RCP&quot; home page is in the platform UI team's web site
viewable only through viewcvs. There are many cross-component, and sometimes
cross-project, issues that need web space. These currently have to be hosted
within a single component's web space and only that team will have commit
rights to it.</li>
<li><b>Moderated Mailing Lists</b>. A small set of mailing lists (eclipse-dev,
platform-ui-dev, possibly swt-dev) could benefit from a moderator. High
density of traffic on the newsgroup means that many people have trouble
getting their questions answered there. They have begun to turn to the mailing
lists as an alternative to newsgroups for getting answers. This is not
surprising - questions on the mailing list are often answered within minutes.
However, if the larger volume of traffic catches on to the idea of using the
mailing lists for user questions, then we will lose a valuable communication
tool for commiters. Perhaps a visible user mailing list would help, but I
think having the ability to switch to moderated lists (starting with
eclipse-dev) is the easiest solution. This moderation would not have to be
stringent - just turn away obvious user questions and point them to the
appropriate newsgroup. There are many committers who would be happy to
participate in a rotating moderator position for eclipse-dev. Better one
committer dealing with the spam than wasting the time of hundreds of people by
letting these messages through.</li>
<li><b>CVS Proxy Support</b>. Support for proxy support for accessing CVS from
inside a firewall. SourceForge already supports this and is very useful for
helping committers/contributors from other companies to work with us. </li>
<li><b>CVS Mirroring</b>. Mirror the CVS tree as well as the downloads tree.</li>
<li><b>QoS Bandwidth Throttling</b>. Allow certain people/machines higher
bandwidth. For example, mirrors and build machines should have higher priority
access to the bandwidth than an average download. (see also 26)</li>
<li><b>Distributed Infrastructure Monitoring and Trouble Tickets</b>. During
the most recent milestone, we had problems with both Bugzilla and CVS going
down. Redundancy would be nice, but ultimately, committers need to be able to
bring these services back up if things go wrong. Right now, we feel like we
don't have the tools we need to communicate with the infrastructure team. We
don't know what to do if we notice a service has gone down, and we never hear
whether the infra team is aware of a problem or when it is fixed. It also
might be nice to distribute some system administrator accounts to non-eclipse.org
people.</li>
<li><b>BitTorrent.</b> Eclipse's Update Manager should support BitTorrent
protocol. Eclipse's download servers ideally should too.<br>
It doesn't matter how many mirrors we have because if we are successful
getting people to use Update Manager, UM is hard-coded to go to the main
Eclipse.org download site. This obviously won't scale. But enabling a
peer-to-peer protocol like BitTorrent within Update Manager would alleviate
this, since BitTorrent causes the clients to also serve the content while
they are downloading. So, your main download server sees roughly constant
bandwidth utilization as as the number of downloads increases rather than
linear or geometric utilization...</li>
<li>...</li>
</ol>
<p>If you are a committer or contributor, we encourage you to
<a href="mailto:eclipse-committers@superboy.org">let us know</a> what your
infrastructure requests are so that we can lobby for them at the Board meetings.
What are your additional requests that are not on the list?</p>
<p>Please vote on the weighting of these items using <a href="http://www.superboy.org/cgi-bin/eclipse-vote.cgi">our
web form</a>. We will use the collective
weights to reorder the list to a highly
prioritized, ordered set of requests for the EMO and the Board at the Dec 8th
Board meeting.</p>
<p>P.S. The <a href="http://www.eclipse.org/emf">EMF</a> project seems to have a
few of these features. For example:</p>
<ul>
<li>Our site's What's New is an XML file which is written to automagically
with every new build promoted to Eclipse. Code for this automagic process is
in CVS in /home/tools/, emf-home/emf-builds/scripts/. See promoteToEclipse.sh</li>
<li>We also have a What's New, CVS? application that takes one-week snapshots
of deltas in CVS, generates those snaps as XML, and then styles that with
PHP+XSL in order to make it searchable/sortable/filterable.</li>
</ul>
<!--
Votes:
<ul>
<li>AR: (12) Servlets and JSP</li>
<li>BFB: (1), (5), (4), (6), (14), (15), (2), (7), (8), (9)</li>
<li>DB: (19)</li>
<li>DM: (19)</li>
<li>DW: (7) Short URLs, (14) Central Password Authentication System, (1)
Project Dashboard/Statistics, (4) Hiearchical Blogs, (12) Servlets and JSP,
(15) Self Management. </li>
<li>MC: (16), (17), (18)</li>
<li>TE: (15) Self Management, (14) Central Password Authentication System, (6)
Reputation System, (11) Subversion, (2) Wikis , (9) Proposals Section</li>
</ul>
-->
</body>
\ No newline at end of file
development/WTPDevelopmentPractice.html 0 → 100644
+ 263
− 0
View file @ 71a11a03
<!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 <A href="sse/PluginOverview.html">PluginOverview.html</A>
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 <A href="sse/SSEDevelopmentPlan.html">SSEDevelopmentPlan.html</A>
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><B>Team Project Set.</B> Each component 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 particular
component.</p>
</li>
<li>
<p><B>Source Folders</B> A minor consistency point: If there's only
one &quot;source directory&quot; it should be named 'src'. If there's
more than one, the additional ones should be named similar to
src-wizards, so its obvious both that's its source, and what its
conceptual division is. Multiple folders are not typically required,
but can be handy when one team has responsibility for one part, and
another team responsibility for another part of the plugin.</p>
</li>
<LI>
<P><B>Compiled code jar.</B> Its recommended the jar for the plugin be
in the "root" of the plugin. Its also recommended a directory such as
"runtime" be reserved for those few cases where a pre-existing binary
jar is shipped with a plugin.</P>
</LI>
<li>
<p><B>cvsignore</B> 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><B>Source Formatting</B> 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>
<LI>
<P><B>Obsolete directories in CVS. </B> If, due to renaming,
refactoring, or just spelling mistakes, a directory in CVS should
literally be deleted, to avoid a large of confusing directories,
please use following procedure. First, if it contains source, its
recommend to version that plugin's source, with a name such as
&quot;obsolete&lt;date&gt;&quot;. Next delete the source, and leave in
its place a single file named &quot;obsolete.txt&quot; . If
appropriate, that file can contain information about why obsolete,
where the replacement is, etc. Lastly, someone will occasionally delete those directories from CVS (not
typically an desirable thing to do, since it is a source code control
system! Note: if some code or project simply become old or outdated, it is usually not appropriate to delete it since it might be required for simple historical reason. In these cases, its recommed to version the final version with some descriptive name like &quot;outdated&lt;date&gt;&quot; and leave a file in the directory called something like &quot;outdated.txt&quot; with some description of when and why, if there's a similar function offered elsewhere, etc. </P>
</LI>
</ul>
</ul>
<H3>Modified Code into CVS</H3>
<P>As features are added to bugzilla and fixes done and patches are
applied, enter the <B>CVS commit comment</B> as<BR>
<CODE>[BUGNO] Bugzilla abstract or explanation (eg: [6788] Fixed NPE on
open) </CODE><BR>
This will allow us to generate a &quot;what is fixed &quot; list
automatically with links to bugzilla with each build. For an example of
output in another project, see <BR>
<A
href="http://download.eclipse.org/tools/emf/scripts/news-release-notes.php?ver=2.1.0#I200411180800">http://download.eclipse.org/tools/emf/scripts/news-release-notes.php?ver=2.1.0#I200411180800</A><BR>
</P>
<H2>Plugin Design Conventions</H2>
<P><B>Avoid using the export=&quot;true&quot; attribute on pre-req
(imported) plugins</B>.
</P>
<P>Its never appropriate to use it just so your upstream clients save
typing a line in their plugin.xml file. But, sometimes it is appropriate
to use it -- when the classes/interfaces in pre-req plugin really are
part of the pre-reqing plugins API. If it fits this later case,
that is it is part of the plugin's API, please document what part of the API requires it. For example: <BR>
<CODE> &lt;!-- need to re-export org.eclipse.text since our API depends
on it, <BR>
such as IStructuredDocument extends IDocument <BR>
--&gt; <BR>
&lt;import plugin=&quot;org.eclipse.text&quot;
export=&quot;true&quot;/&gt; </CODE><BR>The reason for this convention is that it forces upstream clients to stay better aware of exactly what they are pre-reqing instead of picking up some classes simply as a side effect of pre-reqing your plugin. </P>
<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, Streams, 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 changes, to avoid breaking nightly
build), they can do the major changes in a temporary branch. The
component team should keep everyone informed that major development is
occurring in a branch, and naturally, well coordinate the merge back
into the HEAD stream. A good guideline is that development on a branch
should not occur for more than 3 weeks without being merged back into
HEAD.</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>
development/arch_and_design/ArchitectureOverview.html 0 → 100644
+ 527
− 0
View file @ 71a11a03
This diff is collapsed.
development/arch_and_design/images/ModelEditing.png 0 → 100644
+ 0
− 0
View file @ 71a11a03
development/arch_and_design/images/ModelEditing.png

4.29 KiB

development/arch_and_design/images/modelToModel.png 0 → 100644
+ 0
− 0
View file @ 71a11a03
development/arch_and_design/images/modelToModel.png

6.02 KiB

development/arch_and_design/images/server.png 0 → 100644
+ 0
− 0
View file @ 71a11a03
development/arch_and_design/images/server.png

3.54 KiB

development/arch_and_design/images/webAppAndServerTarget.png 0 → 100644
+ 0
− 0
View file @ 71a11a03
development/arch_and_design/images/webAppAndServerTarget.png

5.5 KiB

development/arch_and_design/pq-apis-20041115.ppt 0 → 100644
+ 0
− 0
View file @ 71a11a03
File added
development/arch_and_design/theme/default_style.css 0 → 100644
+ 18
− 0
View file @ 71a11a03
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}
development/contributing.html 0 → 100644
+ 147
− 0
View file @ 71a11a03
<!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>Eclipse Web Tools Platform Project Development</title>
<link rel="stylesheet" href="../../default_style.css" type="text/css">
</head>
<body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" alink="#ff0000">
<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" >
<tr>
<td ALIGN=LEFT width="60%"><font class=indextop>eclipse web tools platform project</font><br>
<font class=indexsub>contributing to the wtp project</font></td>
<td WIDTH="40%">
<img SRC="../../images/Idea.jpg" HSPACE=50 height=86 width=120 align=CENTER></td>
</tr>
</table>
<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" >
<tr>
<td ALIGN=LEFT VALIGN=TOP> <I>This document was inspired by the <A CLASS="external" HREF="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/cdt-home/developer/Commitment.html?cvsroot=Tools_Project" target="_top">Contributing
to the CDT document</A><img class="outlink" src="../jst/images/out.png" alt="" width="6" height="6" /></I>
</td>
</tr>
<tr>
<td ALIGN=LEFT VALIGN=TOP BGCOLOR="#0080C0"><b>
<font face="Arial,Helvetica" color="#FFFFFF">Introduction</font></b></td>
</tr>
<tr>
<td valign="top">
<P>
People often ask, &quot;What does it take to get involved with the development of the WTP?&quot; There are many ways to get involved. On the lightweight end of scale, there is involvement by using the WTP and providing feedback and sharing your experiences on the Eclipse and WTP newsgroups. Beyond that, you can report problems that you discover, so that they may be addressed in future releases. A deeper level of involvement would be to actually solve some of the problems that you or others have uncovered by modifying/writing the necessary code and creating patches that can applied by the project committers. The final, and most beneficial way to get involved is to take responsibility for a significant piece of development work, whether it's enhancing a particular area of the tool or creating new functionality.
<P>
The purpose of this document is to help people and organizations understand what it means to &quot;commit&quot; to WTP Development at this highest level. Basically, it involves a commitment to describe, develop, test and document your contributions.
</td>
</tr>
<tr>
<td ALIGN=LEFT VALIGN=TOP BGCOLOR="#0080C0"><b>
<font face="Arial,Helvetica" color="#FFFFFF">Commitment to Development</font></b></td>
</tr>
<tr>
<td valign="top">
<H4>Communicating Your Desires/Intentions</H4>
<p>The first step involves letting the WTP user community and other WTP development
team members what you propose. The mechanism for this is to create Bugzilla
entries to describe the enhancements or new capabilities you propose to do. The
mailing lists and/or newgroups could also be used for discussing or proposing,
in a more informal way, enhancements or new capabilities. Anyway Bugzilla is seen
here as a central repository of reference for enhancement demands. </p>
<P>
Bugzilla is the open source change management system used by Eclipse projects. To set these Bugzilla entries apart from other problem reports, the word &quot;plan&quot; should be used in the keywords field, and the severity of the entry should be set to &quot;enhancement&quot;. Following these guidelines will ensure that all of these proposals get picked up by the appropriate query and recorded in the plan for the upcoming release.
<P>
Feature specifications (what your code will do) and design specifications (how it will do it) are an important aspect of the development effort. These specifications will allow the WTP community and the rest of the WTP development team to understand what you are doing and to provide feedback. The format of these documents is not important, the content is.
<P>
<H4>Becoming a committer</H4>
<p>Every developer's contribution is welcomed. And by the time, developers can become committers. A committer is a developer who has write access to the source code repository for the associated subproject (or component), and has voting rights allowing to affect the future of the subproject (or component); other developers define patches and submit them, indirectly, through committers. A developer gains such committer rights through frequent and valuable contributions to a subproject, or component of a subproject (in the case of large subprojects). For more information in what it means to be or to become an Eclipse project or subproject committer, see the
<a CLASS="wikipage" href="../project-charter.html">WTP Project Charter</a>. We should point out that creating and submitting quality patches is the best way to obtain committer privileges for future work.
</p>
<P>
<P>
<H4>Delivering the Code</H4>
<p>Once the feature and design documents have been floated to the rest of the WTP community and feedback has been harvested, its time to start pushing the code changes into the development stream. For those that have committer privileges, these changes can be pushed directly into the stream. Those without committer privileges create patches that get reviewed and applied by committers. Patch requests are communicated via
attachments to Bugzilla bugs. Being a committer entails certain responsibilities on its own which won't be discussed here.
</p>
<P>
<H4>Commitment To Testing</H4>
<p>Everyone that contributes content to Eclipse projects is expected to test their contributions. When contributing a significant enhancement or feature, that commitment means more than just assuring the community that the code has been tested. It means documenting a test plan and committing to execute that testing on release candidate builds. The Eclipse way of generating releases is to generate a series of release candidate builds after all of the development has been completed. Each release candidate goes through a test-fix cycle where everyone tests their contributions and communicates their findings. A collective decision is made as to which problems will get fixed for the next release candidate, and the process is repeated. Fewer and fewer fixes will be &quot;blessed&quot; as we progress through the release candidates.
</p>
<P>
So, committing to contribute significant code to the WTP also means committing to participate in the test-fix cycles by executing your test plans against the release candidates build leading up to the final release build.
<P>
<H4>Commitment to Documentation</H4>
<p>An important part of any enhancement or addition to the WTP is making sure that the on-line help of the tool stays current with the changes. The responsibility for updating/modifying/writing the on-line help content that is associated with some part of the tool lies with the contributors of the code. Unless the contributors have commit privileges, the on-line documentation content would get submitted as a patch, much the same as code. And, like code, producing and submitting quality documentation patches is the way to obtain documentation committer privileges.
</p>
<P>
<I>Until a Documentation Style Guide is available for the WTP project, you may
refer to the <A CLASS="external" HREF="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/cdt-home/user/docs.html?cvsroot=Tools_Project" target="_top">CDT
Documentation Style Guide</A> to help maintain a constant look and feel
for documentation originating from different contributors. There also a
couple of links that take you to additional information on how to contribute
help content for Eclipse projects.
<P>
So, finally, committing to contribute code to the WTP also means committing to contributing the associated on-line documentation content for the part of the tool that is being enhanced or created.</i><P></td>
</tr>
</table>
</body>
</html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- Mirrored from wiki.objectweb.org/eclipse-webtools/Wiki.jsp?page=ContributingToTheWTPProject by HTTrack Website Copier/3.x [XR&CO'2003], Fri, 23 Apr 2004 19:12:15 GMT -->
<!-- Mirrored from www.eclipse.org/proposals/eclipse-webtools/Wikiaed0.html by HTTrack Website Copier/3.x [XR&CO'2003], Tue, 25 May 2004 06:27:30 GMT --><head>
<meta http-equiv="content-type" content="text/html;charset=ISO-8859-1">
<meta http-equiv="content-type" content="text/html;charset=ISO-8859-1">
<title>Eclipse Web Tools Platform Project Wiki: Contributing To The WTP Project</title>
<link rel="stylesheet" href="../jst/templates/eclipse/eclipse.css">
</head>
<body>
</body>
<!-- Mirrored from wiki.objectweb.org/eclipse-webtools/Wiki.jsp?page=ContributingToTheWTPProject by HTTrack Website Copier/3.x [XR&CO'2003], Fri, 23 Apr 2004 19:12:15 GMT -->
<meta http-equiv="content-type" content="text/html;charset=ISO-8859-1">
<!-- Mirrored from www.eclipse.org/proposals/eclipse-webtools/Wikiaed0.html by HTTrack Website Copier/3.x [XR&CO'2003], Tue, 25 May 2004 06:27:30 GMT -->
<meta http-equiv="content-type" content="text/html;charset=ISO-8859-1">
</html>
\ No newline at end of file
development/contributor_images/Thumbs.db 0 → 100644
+ 0
− 0
View file @ 71a11a03
File added
development/contributor_images/arthur_ryman.jpg 0 → 100644
+ 0
− 0
View file @ 71a11a03
development/contributor_images/arthur_ryman.jpg

12 KiB

development/contributor_images/craig_salter.jpg 0 → 100644
+ 0
− 0
View file @ 71a11a03
development/contributor_images/craig_salter.jpg

6.03 KiB

development/contributor_images/david_williams.jpg 0 → 100644
+ 0
− 0
View file @ 71a11a03
development/contributor_images/david_williams.jpg

4.18 KiB

development/contributor_images/deniz_secilir.jpg 0 → 100644
+ 0
− 0
View file @ 71a11a03
development/contributor_images/deniz_secilir.jpg

20.6 KiB

development/contributor_images/gorkem_ercan.jpg 0 → 100644
+ 0
− 0
View file @ 71a11a03
development/contributor_images/gorkem_ercan.jpg

13.2 KiB

development/contributor_images/naci_dai.jpg 0 → 100644
+ 0
− 0
View file @ 71a11a03
development/contributor_images/naci_dai.jpg

8.7 KiB

development/contributor_images/no_picture.jpg 0 → 100644
+ 0
− 0
View file @ 71a11a03
development/contributor_images/no_picture.jpg

8.81 KiB

development/contributor_images/tim_deboer.jpg 0 → 100644
+ 0
− 0
View file @ 71a11a03
development/contributor_images/tim_deboer.jpg

11.8 KiB

0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment

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