| <?xml version='1.0'?> |
| <project> |
| <!-- |
| - This example is annotated to be instructive. In order to be instructive, the |
| - example is a mish-mash of information from a variety of projects. Obviously, |
| - when you write the project-info.xml file for your project, the file will |
| - contain information only about your one project. |
| --> |
| <!-- |
| - Unless otherwise specified, all URLs are to be specified using rooted relative |
| - paths. In other words: |
| - CORRECT: "/webtools/foo/bar.php" |
| - INCORRECT: "foo/bar.php" |
| - INCORRECT: "http://www.eclipse.org/webtools/foo/bar.php" |
| --> |
| |
| <!-- Each Eclipse Project has a shortname or nickname --> |
| <short-name>Higgins</short-name> |
| <!-- |
| - Each Eclipse project has one or more Bugzilla products and components. |
| - Some projects also have a separate web page describing how to submit |
| - a bug, how bugs are prioritized, and other useful information. |
| - The <bugzilla> collects this information. |
| - |
| - <bugzilla url="..."> <product name="..."/> ... </bugzilla> |
| - The url is optional; if absent, the url will default to the Bugzilla |
| - page of the first product. Multiple <product>s are allowed. |
| --> |
| <bugzilla> |
| <product name="Higgins"/> |
| </bugzilla> |
| |
| |
| <!-- |
| - Committers and non-committer Contributors are the raison d'etre of |
| - an Eclipse project, thus each project should list and acknowledge these |
| - developers. Some of the Committers are 'special' in the sense that |
| - they are the project leaders. The <committers>, <contributors> and |
| - <leaders> elements contain the URLs of the project's pages listing |
| - these important people. |
| - |
| --> |
| <committers url=""/> |
| <contributors url=""/> |
| <leaders url=""/> |
| |
| <!-- |
| - The source code of each Eclipse project is stored in CVS. Eclipse maintains |
| - a number of CVS repositories, thus the <cvs> element specifies which |
| - CVS repository and (if applicable) which root path stores this project's |
| - source code. |
| - |
| - A top-level project typically specifies only the repository: |
| - <cvs repository="/cvsroot/tptp"/> |
| - A sub-project includes the root path as well: |
| - <cvs repository="/cvsroot/technology/" path="org.eclipse.higgins" /> |
| --> |
| <cvs repository="/cvsroot/technology/" path="org.eclipse.higgins" /> |
| |
| <!-- |
| - The description of an Eclipse project shows up in many places: the |
| - project's home page, perhaps the /projects/ page listing all the |
| - top-level projects, in the Roadmap, and so on. Some of the descriptions |
| - are separate HTML files (such as those described in |
| - http://phoenix.eclipse.org/projects/dev_process/project-status-infrastructure.php). |
| - It would be nice |
| - This <description> element contains two additional descriptions. |
| - 1. The optional <description url="..."> points to a web page with a larger |
| - description of the entire project. |
| - 2. The required <description paragraph-url="..."> points to a file |
| - containing a couple of simple HTML paragraphs describing the project. |
| - This file is often stored in the /project-info/ directory, thus the |
| - url would be something like "/tptp/project-info/description.html". |
| --> |
| <description |
| paragraph-url="/technology/higgins/project-info/project-page-paragraph.html"/> |
| |
| <!-- |
| - In addition to the description, each Eclipse project is also required to |
| - provide an up-to-date status summary. "Up to date" means revised at least |
| - quarterly. |
| - The required <summary paragraph-url="..."> points to a file |
| - containing a number of simple HTML paragraphs with an executive summary |
| - of the project status. |
| - This file is often stored in the /project-info/ directory, thus the |
| - url would be something like "/technology/project-info/executive-summary.html". |
| --> |
| <summary/> |
| |
| <!-- |
| - It is important to help new users get started with an Eclipse project |
| - because most Eclipse projects are solving some difficult technical |
| - problem and thus are somewhat complex. The <getting-started> element |
| - points to a web page on the project's site that describes how to |
| - get started using and extending the project's tools and frameworks. |
| --> |
| <getting-started/> |
| |
| <!-- |
| - Each Eclipse project is required to maintain a current Project IP Log. |
| - See http://www.eclipse.org/projects/dev_process/project-log.php |
| - The <ip-log> contains the URL of that log. |
| - |
| - <ip-log url="..."/> |
| --> |
| <ip-log/> |
| |
| <!-- |
| - Each Eclipse project has one or more mailing lists. |
| - Some projects also have a separate web page describing these lists |
| - while others rely on the main Eclipse mailing lists page. |
| - |
| - <mailing-lists url="..."> <list name="..."/> ... </mailing-lists> |
| - The url is optional; if absent, the url will default to the Eclipse |
| - mailing lists page. Multiple <lists>s are allowed. |
| --> |
| <mailing-lists url="/mail/main.html#higgins"> |
| <list name="higgins-dev"/> |
| </mailing-lists> |
| |
| <!-- |
| - Each Eclipse project has one or more newsgroup. |
| - <newsgroups><newsgroup name="..."> ... </newsgroup> |
| - Multiple <newsgroup> are allowed. |
| --> |
| <newsgroups> |
| <newsgroup name="eclipse.technology.higgins"/> |
| </newsgroups> |
| |
| <!-- |
| - Each Eclipse project can have one or more blog. |
| - <blogs><blog name="name" url="url"/></blogs> |
| --> |
| <blogs> |
| </blogs> |
| |
| <!-- |
| - Each Eclipse project needs to have a plan both for its internal purposes |
| - (to guide development and resource allocation) and for the larger Eclipse |
| - community and ecosystem to understand what will be delivered and when |
| - it will be delivered. |
| --> |
| <project-plan /> |
| |
| <!-- |
| - Each Eclipse project creates (optional) nightly builds and milestone builds, |
| - but the important builds of a project are the releases. This section of the |
| - status file records the completed (past) and scheduled (future) releases of |
| - the project. |
| - The status, name, and date are required attributes. The download is optional |
| - and only valid for completed releases; the plan is optional and valid for |
| - all releases. The three valid types of releases are, in order of ascending |
| - uncertainity: "completed", "scheduled", and "tentative". Dates can be |
| - specified as particular day DD/MM/YYYY (e.g., 22/03/2005) or a particular |
| - month MM/YYYY (e.g., 10/2005), or a quarter NQYYYY (e.g., 3Q2005). Obviously |
| - completed releases should include the exact day the release was completed. |
| - |
| - Scheduled Releaes (status="scheduled") may have Themes and Priorities, for instance what bugs |
| - are being fixed, or what new features will be added (themes) and a list of |
| - critical bugs that really really need to be fixed for that release (priorities) |
| - |
| - In the following example, we have three completed, two scheduled, and one |
| - tentative release. |
| --> |
| <releases> |
| |
| </releases> |
| |
| <!-- |
| - Shipping are an obscure pragma as of yet, but the format is the following: |
| - the date is optional, the value is also optional thus <release url="url"/> |
| - is also valid. |
| - Deprecated by OCM |
| --> |
| |
| </project> |
