Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • eclipsefdn/it/websites/eclipse.org
  • zhoufang/eclipse.org
  • zacharysabourin/eclipse.org
  • oliviergoulet/eclipse.org
  • pkriefrvi/eclipse.org
  • federica/eclipse.org
  • cfrayne/eclipse.org
  • mjahn0qp/eclipse.org
  • davidremon/eclipse.org
  • rosariarossini/eclipse.org
  • chrisguindon/eclipse.org
  • cguindon/eclipse.org
  • jharrisj1m/eclipse.org
  • heurtemattes/eclipse.org
  • sebastienheurtematte/eclipse.org
  • mbarbero/eclipse.org
  • tiagolucas/eclipse.org
  • flzara/eclipse.org
  • wbeaton/eclipse.org
  • gnugomez/eclipse.org
20 results
Show changes
Commits on Source (471)
371 additional commits have been omitted to prevent performance issues.
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 1973 additions and 68 deletions
.gitignore
View file @ da0077de
......@@ -5,4 +5,7 @@
.idea/**
**/.DS_Store
/.project
/data/eclipsefdn_projects.yaml
\ No newline at end of file
/data/eclipsefdn_projects.yaml
.hugo_build.lock
/data/staff_blogs.xml
/bin
\ No newline at end of file
.gitlab-ci.yml 0 → 100644
View file @ da0077de
# You can override the included template(s) by including variable overrides
# SAST customization: https://docs.gitlab.com/ee/user/application_security/sast/#customizing-the-sast-settings
# Secret Detection customization: https://docs.gitlab.com/ee/user/application_security/secret_detection/#customizing-settings
# Dependency Scanning customization: https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#customizing-the-dependency-scanning-settings
# Note that environment variables can be set in several places
# See https://docs.gitlab.com/ee/ci/variables/#cicd-variable-precedence
include:
- project: 'eclipsefdn/it/releng/gitlab-runner-service/gitlab-ci-templates'
file: 'pipeline-autodevops.gitlab-ci.yml'
Jenkinsfile
View file @ da0077de
......@@ -3,7 +3,15 @@
hugo (
appName: 'www.eclipse.org',
productionDomain: 'www.eclipse.org',
branchDomain: "eclipse.org",
previewBranchesRegex: "staging",
build: [
containerImage: 'eclipsefdn/hugo-node:h0.110.0-n18.13.0',
],
quality: [
credentialsId: "sonarcloud-token-eclipse-org"
],
deployment: [
nginxServerConf: 'config/nginx/default.conf'
]
)
)
\ No newline at end of file
README.md
View file @ da0077de
......@@ -2,14 +2,27 @@
The [eclipse.org](https://eclipse.org) website is generated with [Hugo](https://gohugo.io/documentation/).
The Eclipse Foundation provides our global community of individuals and organizations with a mature, scalable, and business-friendly environment for open source software collaboration and innovation.
The Eclipse Foundation provides our global community of individuals and organisations with a mature, scalable, and business-friendly environment for open source software collaboration and innovation.
## Getting started
### Required Software
| Software | Version |
|--- |--- |
| node.js | 18.13.0 |
| npm | 8.19 |
| Hugo | 0.110 |
| Git | > 2.31 |
See our [Managing Required Software](https://gitlab.eclipse.org/eclipsefdn/it/webdev/hugo-solstice-theme/-/wikis/Managing-Required-Software)
wiki page for more information on this topic.
Install dependencies, build assets and start a web server:
```bash
yarn
yarn
hugo server
```
......@@ -38,7 +51,7 @@ Images, less and JavaScript files for the Eclipse Foundation look and feel.
### [EclipseFdn/hugo-solstice-theme](https://gitlab.eclipse.org/eclipsefdn/it/webdev/hugo-solstice-theme/)
Hugo theme of the Eclipse Foundation look and feel.
Hugo theme of the Eclipse Foundation look and feel.
## Bugs and feature requests
......
archetypes/research.md 0 → 100644
View file @ da0077de
---
title: "{{ replace .TranslationBaseName "-" " " | title }}"
date: {{ .Date }}
logo: ""
tags: []
homepage: ""
facebook: ""
linkedin: ""
twitter: ""
youtube: ""
working_groups: []
funding_bodies: []
eclipse_projects: []
project_type: running
---
\ No newline at end of file
config.toml
View file @ da0077de
......@@ -7,10 +7,11 @@ disableKinds = ["taxonomy", "term"]
themesDir = "node_modules/"
enableRobotsTXT = true
pluralizeListTitles = false
disablePathToLower = true
[Params]
google_tag_manager = "GTM-5WLCZXC"
description = "The Eclipse Foundation provides our global community of individuals and organizations with a mature, scalable, and business-friendly environment for open source software collaboration and innovation."
description = "The Eclipse Foundation provides our global community of individuals and organisations with a mature, scalable, and business-friendly environment for open source software collaboration and innovation."
seo_title_suffix = " | The Eclipse Foundation"
keywords = ["eclipse", "project", "plug-ins", "plugins", "java", "ide", "swt", "refactoring", "free java ide", "tools", "platform", "open source", "development environment", "development", "ide"]
news_count = 3
......@@ -19,15 +20,15 @@ pluralizeListTitles = false
gcse = "011805775785170369411:p3ec0igo0qq"
gcse_result_url = "/home/search/"
# eclipse_search_icon = "<i data-feather=\"search\" stroke-width=\"1\"></i>"
js = "public/js/main.js"
js = "public/js/main.js?v1.0"
header_wrapper_class = "header-wrapper"
call_for_action_text = "Download"
call_for_action_url = "/downloads/"
call_for_action_icon = "fa-download"
call_for_action_id = "download-now-top-nav-20250207" # GTM Click ID
share_img = "/images/logos/eclipse-foundation-400x400.png"
logo = "/images/logos/eclipse-foundation-white-orange.svg"
favicon = "/favicon.ico"
logo_width = "160"
layout_style = "astro"
hide_ad = false
# logo_width = ""
# header_left_classes = ""
......@@ -44,7 +45,7 @@ pluralizeListTitles = false
tag = "tags"
[Author]
name = "Christopher Guindon"
name = "Eclipse Foundation"
website = "https://www.eclipse.org"
email = "webdev@eclipse-foundation.org"
facebook = "eclipse.org"
......@@ -60,21 +61,6 @@ pluralizeListTitles = false
plainIDAnchors = true
hrefTargetBlank = true
[[menu.main]]
name = "Projects"
url = "/projects"
weight = 1
[[menu.main]]
name = "Working Groups"
url = "/org/workinggroups"
weight = 2
[[menu.main]]
name = "Members"
url = "/membership"
weight = 3
[[menu.sidebar]]
name = "Eclipse.org"
url = "/home"
......@@ -159,4 +145,642 @@ pluralizeListTitles = false
parent = "contribute"
name = "FAQ"
url = "/contribute/dev-program/faq"
weight = 2
\ No newline at end of file
weight = 2
[[menu.sidebar]]
identifier = "collaborations"
name = "Industry Collaborations"
url = "/collaborations/"
weight = 1
[[menu.sidebar]]
parent = "collaborations"
name = "About Interest Groups"
url = "/collaborations/interest-groups"
weight = 1
# Collaborations Section
[[menu.sidebar]]
parent = "collaborations"
name = "Interest Group Process"
url = "/org/collaborations/interest-groups/process.php"
weight = 2
[[menu.sidebar]]
parent = "collaborations"
name = "Explore our Interest Groups"
url = "/org/workinggroups/explore.php#interest-groups"
weight = 3
# Org section
[[menu.sidebar]]
identifier = "org"
name = "About Us"
url = "/org/"
weight = 1
[[menu.sidebar]]
parent = "org"
name = "Foundation"
url = "/org/foundation/"
weight = 1
[[menu.sidebar]]
parent = "org"
name = "Members & Supporters"
identifier = "org-members"
weight = 2
[[menu.sidebar]]
parent = "org-members"
name = "Our Members"
url = "/membership/explore-membership/"
weight = 1
[[menu.sidebar]]
parent = "org-members"
name = "In-Kind Supporters"
url = "/org/foundation/thankyou.php"
weight = 2
[[menu.sidebar]]
parent = "org"
name = "Services"
identifier = "org-services"
weight = 3
[[menu.sidebar]]
parent = "org-services"
name = "IP Management"
url = "/org/services/#IP_Management"
weight = 1
[[menu.sidebar]]
parent = "org-services"
name = "Ecosystem Development"
url = "/org/services/#Ecosystem"
weight = 2
[[menu.sidebar]]
parent = "org-services"
name = "Development Process"
url = "/org/services/#Development"
weight = 3
[[menu.sidebar]]
parent = "org-services"
name = "IT Infrastructure"
url = "/org/services/#IT"
weight = 4
[[menu.sidebar]]
parent = "org-services"
name = "Marketing Services"
url = "/org/services/marketing/"
weight = 5
[[menu.sidebar]]
parent = "org"
name = "Our Team"
identifier = "org-team"
weight = 4
[[menu.sidebar]]
parent = "org-team"
name = "Eclipse Foundation Staff"
url = "/org/foundation/staff.php"
weight = 1
[[menu.sidebar]]
parent = "org-team"
name = "Contact Us"
url = "/org/foundation/contact.php"
weight = 2
[[menu.sidebar]]
parent = "org-team"
name = "Careers"
url = "/careers/"
weight = 3
[[menu.sidebar]]
parent = "org"
name = "Governance"
identifier = "org-governance"
weight = 5
[[menu.sidebar]]
parent = "org-governance"
name = "Board of Directors"
url = "/org/foundation/directors.php"
weight = 1
[[menu.sidebar]]
parent = "org-governance"
name = "Board of Directors Elections"
url = "/org/elections/"
weight = 2
[[menu.sidebar]]
parent = "org-governance"
name = "Councils"
url = "/org/foundation/council.php"
weight = 3
[[menu.sidebar]]
parent = "org-governance"
name = "Annual Report"
url = "/org/foundation/reports/annual_report.php"
weight = 4
[[menu.sidebar]]
parent = "org-governance"
name = "Governance Documents"
url = "/org/documents/"
weight = 5
[[menu.sidebar]]
parent = "org-governance"
name = "Meeting Minutes"
url = "/org/foundation/minutes.php"
weight = 6
[[menu.sidebar]]
parent = "org"
name = "Our Brand"
identifier = "org-brand"
weight = 6
[[menu.sidebar]]
parent = "org-brand"
name = "Logos and Artwork"
url = "/org/artwork/"
weight = 1
[[menu.sidebar]]
parent = "org-brand"
name = "Eclipse Foundation Brand Guidelines"
url = "/legal/documents/eclipse_foundation_branding_guidelines.pdf"
weight = 2
[[menu.sidebar]]
parent = "org-brand"
name = "Trademark Usage Guidelines"
url = "/legal/logo-guidelines/"
weight = 3
[[menu.sidebar]]
parent = "org-brand"
name = "Writing Style Guide"
url = "/org/documents/writing-style-guide/"
weight = 4
[[menu.sidebar]]
parent = "org"
name = "Announcements"
identifier = "org-announcements"
weight = 7
[[menu.sidebar]]
parent = "org-announcements"
name = "Press Releases"
url = "https://newsroom.eclipse.org/news/press-releases"
weight = 1
[[menu.sidebar]]
parent = "org-announcements"
name = "PR Guidelines"
url = "/org/press-release/guidelines/"
weight = 2
[[menu.sidebar]]
parent = "org-announcements"
name = "2006 Archive"
url = "/org/press-release/2006archive.php"
weight = 3
[[menu.sidebar]]
parent = "org-announcements"
name = "2001-2005 Archive"
url = "/org/press-release/main.html"
weight = 4
# Membership Section
[[menu.sidebar]]
identifier = "membership"
name = "Membership"
url = "/membership/"
weight = 1
[[menu.sidebar]]
parent = "membership"
name = "Explore Members"
url = "/membership/explore-membership"
weight = 1
[[menu.sidebar]]
parent = "membership"
name = "Become a Member"
url = "/membership/become-a-member"
weight = 2
[[menu.sidebar]]
parent = "membership"
name = "Members FAQ"
url = "/membership/faq"
weight = 3
# Security Section
[[menu.sidebar]]
identifier = "security"
name = "Security"
url = "/security"
weight = 1
[[menu.sidebar]]
parent = "security"
name = "Known Vulnerabilities"
url = "/security/known"
pre = "<i class=\"fa fa-caret-right fa-fw\"></i>"
weight = 1
[[menu.sidebar]]
parent = "security"
name = "Mail the Security Team"
url = "mailto:security@eclipse-foundation.org"
pre = "<i class=\"fa fa-caret-right fa-fw\"></i>"
weight = 1
[[menu.sidebar]]
parent = "security"
name = "Team Members"
url = "/security/team"
pre = "<i class=\"fa fa-caret-right fa-fw\"></i>"
weight = 2
[[menu.sidebar]]
parent = "security"
name = "Policy"
url = "/security/policy"
pre = "<i class=\"fa fa-caret-right fa-fw\"></i>"
weight = 3
# Legal Section
[[menu.sidebar]]
identifier = "legal"
name = "Legal"
url = "/legal"
weight = 1
[[menu.sidebar]]
parent = "legal"
name = "ECA"
identifier = "legal-eca"
weight = 1
[[menu.sidebar]]
parent = "legal-eca"
name = "About"
identifier = "legal-eca-about"
weight = 1
url = "/legal/eca"
[[menu.sidebar]]
parent = "legal-eca"
name = "Sign"
weight = 2
url = "https://accounts.eclipse.org/user/eca"
[[menu.sidebar]]
parent = "legal-eca"
name = "Validation Tool"
weight = 3
url = "https://accounts.eclipse.org/user/eca"
[[menu.sidebar]]
parent = "legal"
name = "EPL-2.0"
identifier = "legal-epl-20"
weight = 2
[[menu.sidebar]]
parent = "legal-epl-20"
name = "About"
identifier = "legal-epl-20-about"
weight = 1
url = "/legal/epl-2.0/"
[[menu.sidebar]]
parent = "legal-epl-20"
name = "Plain HTML"
identifier = "legal-epl-20-html"
weight = 2
url = "/org/documents/epl-2.0/EPL-2.0.html"
[[menu.sidebar]]
parent = "legal-epl-20"
name = "Plain Text"
identifier = "legal-epl-20-text"
weight = 3
url = "/org/documents/epl-2.0/EPL-2.0.txt"
[[menu.sidebar]]
parent = "legal-epl-20"
name = "PDF"
identifier = "legal-epl-20-pdf"
weight = 4
url = "/org/documents/epl-2.0/EPL-2.0.pdf"
[[menu.sidebar]]
parent = "legal-epl-20"
name = "FAQ"
identifier = "legal-epl-20-faq"
weight = 5
url = "/legal/epl-2.0/faq/"
[[menu.sidebar]]
parent = "legal"
name = "EPL-1.0"
identifier = "legal-epl-10"
weight = 3
[[menu.sidebar]]
parent = "legal-epl-10"
name = "About"
identifier = "legal-epl-10-about"
weight = 1
url = "/org/documents/epl-v10.php"
[[menu.sidebar]]
parent = "legal-epl-10"
name = "Plain HTML"
identifier = "legal-epl-10-html"
weight = 2
url = "/org/documents/epl-v10.html"
[[menu.sidebar]]
parent = "legal-epl-10"
name = "Plain Text"
identifier = "legal-epl-10-text"
weight = 3
url = "/org/documents/epl-1.0/EPL-1.0.txt"
[[menu.sidebar]]
parent = "legal-epl-10"
name = "FAQ"
identifier = "legal-epl-10-faq"
weight = 4
url = "/legal/epl/faq"
[[menu.sidebar]]
parent = "legal"
name = "Licenses"
identifier = "legal-licenses"
weight = 4
[[menu.sidebar]]
parent = "legal-licenses"
name = "Approved 3rd Party"
weight = 1
url = "/legal/licenses#approved"
[[menu.sidebar]]
parent = "legal-licenses"
name = "Non Approved"
weight = 2
url = "/legal/licenses#nonapproved"
[[menu.sidebar]]
parent = "legal-licenses"
name = "File Headers"
weight = 3
url = "/projects/handbook/#ip-copyright-headers"
[[menu.sidebar]]
parent = "legal-licenses"
name = "Docs & Examples"
weight = 4
url = "/legal/non-code-licenses"
[[menu.sidebar]]
parent = "legal"
name = "Specifications"
identifier = "legal-specs"
weight = 5
[[menu.sidebar]]
parent = "legal-specs"
name = "Specifications Process"
weight = 1
url = "/projects/efsp/"
[[menu.sidebar]]
parent = "legal-specs"
name = "Specifications Operations"
weight = 2
url = "/projects/efsp/operations.php"
[[menu.sidebar]]
parent = "legal-specs"
name = "Specification License"
weight = 3
url = "/legal/efsl"
[[menu.sidebar]]
parent = "legal-specs"
name = "TCK License"
weight = 4
url = "/legal/tck"
# About Us (org) Section
[[menu.sidebar]]
identifier = "org"
name = "About Us"
url = "/org/"
weight = 1
[[menu.sidebar]]
parent = "org"
name = "Foundation"
url = "/org/foundation/"
weight = 1
[[menu.sidebar]]
parent = "org"
name = "Members & Supporters"
identifier = "org-members-and-supporters"
weight = 2
[[menu.sidebar]]
parent = "org-members-and-supporters"
name = "Our Members"
url = "/membership/explore-membership/"
weight = 1
[[menu.sidebar]]
parent = "org-members-and-supporters"
name = "In-Kind Supporters"
url = "/org/foundation/thankyou.php"
weight = 3
[[menu.sidebar]]
parent = "org"
name = "Services"
identifier = "org-services"
weight = 3
[[menu.sidebar]]
parent = "org-services"
name = "IP Management"
url = "/org/services/#IP_Management"
weight = 1
[[menu.sidebar]]
parent = "org-services"
name = "Ecosystem Development"
url = "/org/services/#Ecosystem"
weight = 2
[[menu.sidebar]]
parent = "org-services"
name = "Development Process"
url = "/org/services/#Development"
weight = 3
[[menu.sidebar]]
parent = "org-services"
name = "IT Infrastructure"
url = "/org/services/#IT"
weight = 4
[[menu.sidebar]]
parent = "org-services"
name = "Marketing Services"
url = "/org/services/marketing"
weight = 5
[[menu.sidebar]]
parent = "org"
name = "Our Team"
identifier = "org-team"
weight = 4
[[menu.sidebar]]
parent = "org-team"
name = "Eclipse Foundation Staff"
url = "/org/foundation/staff/"
weight = 1
[[menu.sidebar]]
parent = "org-team"
name = "Contact Us"
url = "/org/foundation/contact.php"
weight = 2
[[menu.sidebar]]
parent = "org-team"
name = "Careers"
url = "/careers/"
weight = 3
[[menu.sidebar]]
parent = "org"
name = "Governance"
identifier = "org-governance"
weight = 5
[[menu.sidebar]]
parent = "org-governance"
name = "Board of Directors"
url = "/org/foundation/directors.php"
weight = 1
[[menu.sidebar]]
parent = "org-governance"
name = "Board of Directors Elections"
url = "/org/elections/"
weight = 2
[[menu.sidebar]]
parent = "org-governance"
name = "Councils"
url = "/org/foundation/council.php"
weight = 3
[[menu.sidebar]]
parent = "org-governance"
name = "Annual Report"
url = "/org/foundation/reports/annual_report.php"
weight = 4
[[menu.sidebar]]
parent = "org-governance"
name = "Governance Documents"
url = "/org/documents/"
weight = 5
[[menu.sidebar]]
parent = "org-governance"
name = "Meeting Minutes"
url = "/org/foundation/minutes.php"
weight = 6
[[menu.sidebar]]
parent = "org"
name = "Our Brand"
identifier = "org-brand"
weight = 6
[[menu.sidebar]]
parent = "org-brand"
name = "Logos and Artwork"
url = "/org/foundation/artwork/"
weight = 1
[[menu.sidebar]]
parent = "org-brand"
name = "Eclipse Foundation Brand Guidelines"
url = "/org/legal/documents/eclipse_foundation_branding_guidelines.pdf"
weight = 2
[[menu.sidebar]]
parent = "org-brand"
name = "Trademark Usage Guidelines"
url = "/legal/logo_guidelines/"
weight = 3
[[menu.sidebar]]
parent = "org-brand"
name = "Writing Style Guide"
url = "/org/documents/writing-style-guide/"
weight = 4
[[menu.sidebar]]
parent = "org"
name = "Announcements"
identifier = "org-announcements"
weight = 7
[[menu.sidebar]]
parent = "org-announcements"
name = "Press Releases"
url = "/org/press-release/"
weight = 1
[[menu.sidebar]]
parent = "org-announcements"
name = "PR Guidelines"
url = "/org/press-release/guidelines/"
weight = 2
[[menu.sidebar]]
parent = "org-announcements"
name = "2006 Archive"
url = "/org/press-release/2006archive.php"
weight = 3
[[menu.sidebar]]
parent = "org-announcements"
name = "2001-2005 Archive"
url = "/org/press-release/main.html"
weight = 4
config/nginx/default.conf
View file @ da0077de
This diff is collapsed.
content/_index.md
View file @ da0077de
......@@ -2,7 +2,7 @@
title: Home
headline: The Community for Open Innovation and Collaboration
tagline: The Eclipse Foundation provides our global community of individuals and
organizations with a mature, scalable, and business-friendly environment for
organisations with a mature, scalable, and business-friendly environment for
open source software collaboration and innovation.
hide_page_title: true
redirect_url: /home/
......@@ -14,18 +14,17 @@ layout: single
links:
- - href: /projects/
- text: Discover Projects
- - href: /org/workinggroups/
- text: Working Group
- - href: /collaborations
- text: Industry Collaborations
- - href: /membership/
- text: Members
- - href: /org/value
- text: Business Value
container: container-fluid
lastmod: 2022-04-29T14:50:37.859Z
header_wrapper_class: header-wrapper header-anniversary-bg-img header-default-bg-img
featured-jumbotron-bottom-shape
header_wrapper_class: header-default-bg-img
description: The Eclipse Foundation provides our global community of individuals and
organizations with a mature, scalable, and business-friendly environment for
organisations with a mature, scalable, and business-friendly environment for
open source software collaboration and innovation.
keywords:
- eclipse
......@@ -46,4 +45,4 @@ keywords:
- eclipse foundation
---
This page is not available on production. Redirecting to homepage...
\ No newline at end of file
This page is not available on production. Redirecting to homepage...
content/articles/Article-API-Use/about.xml 0 → 100644
View file @ da0077de
<?xml version="1.0" encoding="iso-8859-1"?>
<article link="eclipse-api-usage-rules.html">
<title>How to Use the Eclipse API</title>
<category>Plug-ins</category>
<update>
<date>May 18, 2001</date>
</update>
<author>
<name><![CDATA[Jim des Rivi&egrave;res]]></name>
<company>IBM</company>
</author>
<description>
The Eclipse Platform offers a comprehensive API (Application
Programmer Interface) to developers writing plug-ins. This
article discusses the general ground rules for using the Eclipse
Platform API, including how to tell API from non-API, and how to
stay in the API "sweet spot" to avoid the risk of being broken
as the platform and its APIs evolve. These general ground rules
are also recommended practice for plug-ins that must declare API
elements of their own.
</description>
</article>
\ No newline at end of file
content/articles/Article-API-Use/eclipse-api-usage-rules.html 0 → 100644
View file @ da0077de
<!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="Mozilla/4.5 [en] (Win98; I) [Netscape]">
<meta name="Author" content="Jim des Rivières">
<title>API Rules of Engagement</title>
<link rel="stylesheet" href="../default_style.css">
</head>
<body>
<div align=right><font face="Times New Roman, Times, serif"><font size=-1>Copyright
&copy; 2001 Object Technology International, Inc.</font></font></div>
<div ALIGN=right><table BORDER=0 CELLSPACING=0 CELLPADDING=2 WIDTH="100%" >
<tr>
<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica"><font color="#FFFFFF">&nbsp;Eclipse
Corner Article</font></font></b></td>
</tr>
</table></div>
<h1>
<img SRC="idea.jpg" height=86 width=120></h1>
<center>
<h1>
How to Use the Eclipse API</h1></center>
<blockquote><b>Summary</b>
<br>The Eclipse Platform offers a comprehensive API (Application Programmer
Interface) to developers writing plug-ins. This article discusses the general
ground rules for using the Eclipse Platform API, including how to tell
API from non-API, and how to stay in the API "sweet spot" to avoid the
risk of being broken as the platform and its APIs evolve. These general
ground rules are also recommended practice for plug-ins that must declare
API elements of their own.
<p><b>By Jim des Rivi&egrave;res, OTI</b>
<br><font size=-1>Updated May 18, 2001</font></blockquote>
<hr WIDTH="100%">
<h3>
What it means to be API</h3>
The Eclipse platform defines API elements for use by its clients, namely
ISVs writing plug-ins. These plug-ins may in turn define API elements for
their clients, and so on. API elements are the public face: they carry
a specification about what they are supposed to do, and about how they
are intended to be used. API elements are supported: the Eclipse platform
team will fix implementation bugs where there is a deviation from the specified
behavior. Since there is often a high cost associated with breaking API
changes, the Eclipse platform team will also try to evolve API elements
gracefully through successive major releases.
<h3>
How to tell API from non-API</h3>
By their very nature, API elements are documented and have a specification,
in contrast to non-API elements which are internal implementation details
usually without published documentation or specifications. So if you cannot
find the documentation for something, that's usually a good indicator that
it's not API.
<p>To try to draw the line more starkly, the code base for the platform
is separated into API and non-API packages, with all API elements being
declared in designated API packages.
<ul>
<li>
<b>API package</b> - a Java&trade; package that contains at least one API class
or API interface. The names of API packages are advertised in the documentation
for that component; where feasible, all other packages containing only
implementation details have "internal" in the package name. The names of
API packages may legitimately appear in client code. For the Eclipse platform
proper, these are:</li>
<ul>
<li>
<tt>org.eclipse.foo.*</tt> - for example, <tt>org.eclipse.swt.widgets</tt>,
<tt>org.eclipse.ui</tt>,
or <tt>org.eclipse.core.runtime</tt></li>
<li>
<tt>org.eclipse.foo.internal.*</tt> - not API; internal implementation
packages</li>
<li>
<tt>org.eclipse.foo.examples.*</tt> - not API; these are examples</li>
<li>
<tt>org.eclipse.foo.tests.*</tt> - not API; these are test suites</li>
</ul>
<li>
<b>API class or interface</b> - a <tt>public</tt> class or interface in
an API package, or a <tt>public</tt> or <tt>protected</tt> class or interface
member declared in, or inherited by, some other API class or interface.
The names of API classes and interfaces may legitimately appear in client
code.</li>
<li>
<b>API method or constructor</b> - a <tt>public</tt> or <tt>protected</tt>
method or constructor either declared in, or inherited by, an API class
or interface. The names of API methods may legitimately appear in client
code.</li>
<li>
<b>API field</b> - a <tt>public</tt> or <tt>protected</tt> field either
declared in, or inherited by, an API class or interface. The names of API
fields may legitimately appear in client code.</li>
</ul>
Everything else is considered internal implementation detail and off limits
to all clients. Legitimate client code must never reference the names of
non-API elements (not even using Java reflection). In some cases, the Java
language's name accessibility rules are used to disallow illegal references.
However, there are many cases where this is simply not possible. Observing
this one simple rule avoids the problem completely:
<ul>
<li>
<b>Stick to officially documented APIs. </b>Only reference packages that
are documented in the <b><i>published API Javadoc</i></b> for the component.
Never reference a package belonging to another component that has "internal"
in its name---these are never API. Never reference a package for which
there is no published API Javadoc---these are not API either.</li>
</ul>
<h3>
General Rules</h3>
The specification of API elements is generated from Javadoc comments in
the element's Java source code. For some types of elements, the specification
is in the form of a contract. For example, in the case of methods, the
contract is between two parties, the caller of the method and the implementor
of the method. The fundamental ground rule is:
<ul>
<li>
<b>Honor all contracts.</b> The contracts are described in the published
Javadoc for the API elements you are using.</li>
</ul>
The term "must", when used in an API contract, means that it is incumbent
on the party to ensure that the condition would always be met; any failure
to do so would be considered a programming error with unspecified (and
perhaps unpredictable) consequences.
<ul>
<li>
<b>You must honor "must". </b>Pay especially close heed to conditions where
"must" is used.</li>
</ul>
Other common sense rules:
<ul>
<li>
<b>Do not rely on incidental behavior. </b>Incidental behavior is behavior
observed by experiment or in practice, but which is not guaranteed by any
API specification.</li>
<li>
<b>Do not treat null as an object.</b> Null is more the lack of an object.
Assume everything is non-null unless the API specification says otherwise.</li>
<li>
<b>Do not try to cheat with Java reflection.</b> Using Java reflection
to circumvent Java compiler checking buys you nothing more. There are no
additional API contracts for uses of reflection; reflection simply increases
the likelihood of relying on unspecified behavior and internal implementation
detail.</li>
<li>
<b>Use your own packages. </b>Do not declare code in a package belonging
to another component. Always declare your own code in your own packages.</li>
</ul>
<h3>
Calling public API methods</h3>
For most clients, the bulk of the Eclipse API takes the form of public
methods on API interfaces or classes, provided for the client to call when
appropriate.
<ul>
<li>
<b>Ensure preconditions.</b> Do ensure that an API method's preconditions
are met before calling the method. Conversely, the caller may safely assume
that the method's postconditions will have been achieved immediately upon
return from the call.</li>
<li>
<b>Null parameters.</b> Do not pass null as a parameter to an API method
unless the parameter is explicitly documented as allowing null. This is
perhaps the most frequently made programming error.</li>
<li>
<b>Restricted callers.</b> Do not call an API method that is documented
as available only to certain callers unless you're one of them. In some
situations, methods need to be part of the public API for the benefit of
a certain class of callers (often internal); calling one of these methods
at the wrong time has unspecified (and perhaps unpredictable) consequences.</li>
<li>
<b>Debugging methods.</b> Do not call an API method labelled "for debugging
purposes only". For example, most <tt>toString()</tt> methods are in this
category.</li>
<li>
<b>Parameter capture.</b> Do not pass an array, collection, or other mutable
object as a parameter to an API method and then modify the object passed
in. This is just asking for trouble.</li>
</ul>
<h3>
Instantiating platform API classes</h3>
Not all concrete API classes are intended to be instantiated by just anyone.
API classes have an instantiation contract indicating the terms under which
instances may be created. The contract may also cover things like residual
initialization responsibilities (for example, configuring a certain property
before the instance is fully active) and associated lifecycle responsibilities
(for example, calling <tt>dispose()</tt> to free up OS resources hung on
to by the instance). Classes that are designed to be instantiated by clients
are explicitly flagged in the Javadoc class comment (with words like "Clients
may instantiate.").
<ul>
<li>
<b>Restricted instantiators.</b> Do not instantiate an API class that is
documented as available only to certain parties unless you're one of them.
In some situations, classes need to be part of the public API for the benefit
of a certain party (often internal); instantiating one of these classes
incorrectly has unspecified (and perhaps unpredictable) consequences.</li>
</ul>
<h3>
Subclassing platform API classes</h3>
Only a subset of the API classes were designed to be subclassed. API classes
have a subclass contract indicating the terms under which subclasses may
be declared. This contract also covers initialization responsibilities
and lifecycle responsibilities. Classes that are designed to be subclassed
by clients are explicitly flagged in the Javadoc class comment (with words
like "Clients may subclass.").
<ul>
<li>
<b>Restricted subclassers.</b> Do not subclass an API class that is not
intended to be subclassed. Treat these classes as if they had been declared
final. (These are sometimes referred to as "soft final" classes).</li>
</ul>
<h3>
Calling protected API methods</h3>
Calling inherited protected and public methods from within a subclass is
generally allowed; however, this often requires more care to correctly
call than to call public methods from outside the hierarchy.
<h3>
Overriding API methods</h3>
Only a subset of the public and protected API methods were designed to
be overridden. Each API method has a subclass contract indicating the terms
under which a subclass may override it. By default, overriding is not permitted.
It is important to check the subclass contract on the actual method implementation
being overridden; the terms of subclass contracts are not automatically
passed along when that method is overridden.
<ul>
<li>
<b>Do not override a public or protected API method unless it is explicitly
allowed.</b> Unless otherwise indicated, treat all methods as if they had
been declared final. (These are sometimes known as "soft final" methods).
If the kind of overriding allowed is:</li>
<ul>"<b>implement</b>" - the abstract method declared on the subclass must
be implemented by a concrete subclass
<br>"<b>extend</b>" - the method declared on the subclass must invoke the
method on the superclass (exactly once)
<br>"<b>re-implement</b>" - the method declared on the subclass must not
invoke the method on the superclass
<br>"<b>override</b>" - the method declared on the subclass is free to
invoke the method on the superclass as it sees fit</ul>
<li>
<b>Ensure postconditions. </b>Do ensure that any postconditions specified
for the API method are met by the implementation upon return.</li>
<li>
<b>Proactively check preconditions. </b>Do not presume that preconditions
specified for the API method have necessarily been met upon entry. Although
the method implementation would be within its rights to not check specified
preconditions, it is usually a good idea to check preconditions (when feasible
and reasonably inexpensive) in order to blow the whistle on misbehaving
callers.</li>
<li>
<b>Null result. </b>Do not return null as a result from an API method unless
the result is explicitly documented (on the specifying interface or superclass)
as allowing null.</li>
<li>
<b>Return copies. </b>Do not return an irreplaceable array, collection,
or other mutable object as the result from an API method. Always return
a copy to avoid trouble from callers that might modify the object.</li>
</ul>
<h3>
Implementing platform API interfaces</h3>
Only a subset of the API interfaces were designed to be implemented by
clients. API interfaces have a contract indicating the terms under which
it may be implemented. Interfaces that are designed to be implemented by
clients are explicitly flagged in the Javadoc class comment (with words
like "Clients may implement."). A client may declare a subinterface of
an API interface if and only if they are allowed to implement it.
<ul>
<li>
<b>Restricted implementors.</b> Do not implement an API interface that
is documented as available only to certain parties unless you're one of
them. In many situations, interfaces are used to hide internal implementation
details from view.</li>
</ul>
<h3>
Implementing public API methods</h3>
See "Overriding API methods".
<h3>
Accessing Fields in API classes and interfaces</h3>
Clients may read API fields, most of which are final. Certain struct-like
objects may have non-final public fields, which clients may read and write
unless otherwise indicated.
<ul>
<li>
<b>Null fields.</b> Do not set an API field to null unless this is explicitly
allowed.</li>
</ul>
<h3>
Casting Objects of a known API type</h3>
An object of a known API type may only be cast to a different API type
(or conditionally cast using instanceof) if this is explicitly allowed
in the API.
<ul>
<li>
<b>Cast and instanceof.</b> Do not use instanceof and cast expressions
to increase what is known about an object beyond what the API supports.
Improper use exposes incidental implementation details not guaranteed by
the API.</li>
</ul>
And, of course, casting any object to a non-API class or interface is always
inappropriate.
<h3>
Not Following the Rules</h3>
Whether done knowingly or unwittingly, there are consequences for transgressing
the rules. It might be easier for all involved if there were API police that would
bust you for breaking the rules. However, that is not the case. For the most part,
API conformance operates as an honor system, with each client responsible for
knowing the rules and adhering to them.
<p>The contracts on the API elements delimit the behavior that is supported
and sustained. As the Eclipse platform matures and evolves, it will be
the API contracts that guide how this evolution happens. Outside of these
contracts, everything is unsupported and subject to change, without notice,
and at any time (even mid-release or between different OS platforms). Client
code that oversteps the above rules might fail on different versions and
patch levels of the platform; or when run on different underlying OSes;
or when run with a different mix of co-resident plug-ins; or when run with
a different workbench perspective; and so on. Indeed, no one is even particularly
interested in speculating exactly how any particular transgression might
come back to bite you. To those who choose to ignore the rules, don't say
that you weren't warned. And don't expect much more than a sympathetic
"Told you so."
<p>On the other hand, client plug-in code that lives by the above rules
should continue to work across different versions and patch levels of the
platform, across different underlying OSes, and should peacefully co-exist
with other plug-ins. If everyone plays by the rules, the Eclipse platform
will provide a stable and supported base on which to build exciting new
products.
<p><small>Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States, other countries, or
both.</small></p>
</body>
</html>
content/articles/Article-API-Use/index.html 0 → 100644
View file @ da0077de
<!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="Mozilla/4.5 [en] (Win98; I) [Netscape]">
<meta name="Author" content="Jim des Rivières">
<title>API Rules of Engagement</title>
<link rel="stylesheet" href="../article.css">
</head>
<body>
<h1>How to Use the Eclipse API</h1>
<div class="summary">
<h2>Summary</h2>
<p>The Eclipse Platform offers a comprehensive API (Application
Programmer Interface) to developers writing plug-ins. This article
discusses the general ground rules for using the Eclipse Platform API,
including how to tell API from non-API, and how to stay in the API
"sweet spot" to avoid the risk of being broken as the platform and its
APIs evolve. These general ground rules are also recommended practice
for plug-ins that must declare API elements of their own.</p>
<div class="author">By Jim des Rivi&egrave;res, OTI</div>
<div class="copyright">Copyright &copy; 2001 Object Technology
International, Inc.</div>
<div class="date">Updated May 18, 2001</div>
</div>
<div class="content">
<h3>What it means to be API</h3>
<p>The Eclipse platform defines API elements for use by its clients, namely
ISVs writing plug-ins. These plug-ins may in turn define API elements
for their clients, and so on. API elements are the public face: they
carry a specification about what they are supposed to do, and about how
they are intended to be used. API elements are supported: the Eclipse
platform team will fix implementation bugs where there is a deviation
from the specified behavior. Since there is often a high cost associated
with breaking API changes, the Eclipse platform team will also try to
evolve API elements gracefully through successive major releases.</p>
<h3>How to tell API from non-API</h3>
<p>By their very nature, API elements are documented and have a
specification, in contrast to non-API elements which are internal
implementation details usually without published documentation or
specifications. So if you cannot find the documentation for something,
that's usually a good indicator that it's not API.</p>
<p>To try to draw the line more starkly, the code base for the
platform is separated into API and non-API packages, with all API
elements being declared in designated API packages.</p>
<ul>
<li><b>API package</b> - a Java&trade; package that contains at
least one API class or API interface. The names of API packages are
advertised in the documentation for that component; where feasible, all
other packages containing only implementation details have "internal"
in the package name. The names of API packages may legitimately appear
in client code. For the Eclipse platform proper, these are:</li>
<ul>
<li><tt>org.eclipse.foo.*</tt> - for example, <tt>org.eclipse.swt.widgets</tt>,
<tt>org.eclipse.ui</tt>, or <tt>org.eclipse.core.runtime</tt></li>
<li><tt>org.eclipse.foo.internal.*</tt> - not API; internal
implementation packages</li>
<li><tt>org.eclipse.foo.examples.*</tt> - not API; these are
examples</li>
<li><tt>org.eclipse.foo.tests.*</tt> - not API; these are test
suites</li>
</ul>
<li><b>API class or interface</b> - a <tt>public</tt> class or
interface in an API package, or a <tt>public</tt> or <tt>protected</tt>
class or interface member declared in, or inherited by, some other API
class or interface. The names of API classes and interfaces may
legitimately appear in client code.</li>
<li><b>API method or constructor</b> - a <tt>public</tt> or <tt>protected</tt>
method or constructor either declared in, or inherited by, an API class
or interface. The names of API methods may legitimately appear in
client code.</li>
<li><b>API field</b> - a <tt>public</tt> or <tt>protected</tt>
field either declared in, or inherited by, an API class or interface.
The names of API fields may legitimately appear in client code.</li>
</ul>
<p>Everything else is considered internal implementation detail and off
limits to all clients. Legitimate client code must never reference the
names of non-API elements (not even using Java reflection). In some
cases, the Java language's name accessibility rules are used to disallow
illegal references. However, there are many cases where this is simply
not possible. Observing this one simple rule avoids the problem
completely:</p>
<ul>
<li><b>Stick to officially documented APIs. </b>Only reference
packages that are documented in the <b><i>published API Javadoc</i></b>
for the component. Never reference a package belonging to another
component that has "internal" in its name---these are never API. Never
reference a package for which there is no published API Javadoc---these
are not API either.</li>
</ul>
<h3>General Rules</h3>
<p>The specification of API elements is generated from Javadoc comments in
the element's Java source code. For some types of elements, the
specification is in the form of a contract. For example, in the case of
methods, the contract is between two parties, the caller of the method
and the implementor of the method. The fundamental ground rule is:</p>
<ul>
<li><b>Honor all contracts.</b> The contracts are described in the
published Javadoc for the API elements you are using.</li>
</ul>
<p>The term "must", when used in an API contract, means that it is
incumbent on the party to ensure that the condition would always be met;
any failure to do so would be considered a programming error with
unspecified (and perhaps unpredictable) consequences.</p>
<ul>
<li><b>You must honor "must". </b>Pay especially close heed to
conditions where "must" is used.</li>
</ul>
<p>Other common sense rules:</p>
<ul>
<li><b>Do not rely on incidental behavior. </b>Incidental behavior
is behavior observed by experiment or in practice, but which is not
guaranteed by any API specification.</li>
<li><b>Do not treat null as an object.</b> Null is more the lack
of an object. Assume everything is non-null unless the API
specification says otherwise.</li>
<li><b>Do not try to cheat with Java reflection.</b> Using Java
reflection to circumvent Java compiler checking buys you nothing more.
There are no additional API contracts for uses of reflection;
reflection simply increases the likelihood of relying on unspecified
behavior and internal implementation detail.</li>
<li><b>Use your own packages. </b>Do not declare code in a package
belonging to another component. Always declare your own code in your
own packages.</li>
</ul>
<h3>Calling public API methods</h3>
<p>For most clients, the bulk of the Eclipse API takes the form of public
methods on API interfaces or classes, provided for the client to call
when appropriate.</p>
<ul>
<li><b>Ensure preconditions.</b> Do ensure that an API method's
preconditions are met before calling the method. Conversely, the caller
may safely assume that the method's postconditions will have been
achieved immediately upon return from the call.</li>
<li><b>Null parameters.</b> Do not pass null as a parameter to an
API method unless the parameter is explicitly documented as allowing
null. This is perhaps the most frequently made programming error.</li>
<li><b>Restricted callers.</b> Do not call an API method that is
documented as available only to certain callers unless you're one of
them. In some situations, methods need to be part of the public API for
the benefit of a certain class of callers (often internal); calling one
of these methods at the wrong time has unspecified (and perhaps
unpredictable) consequences.</li>
<li><b>Debugging methods.</b> Do not call an API method labelled
"for debugging purposes only". For example, most <tt>toString()</tt>
methods are in this category.</li>
<li><b>Parameter capture.</b> Do not pass an array, collection, or
other mutable object as a parameter to an API method and then modify
the object passed in. This is just asking for trouble.</li>
</ul>
<h3>Instantiating platform API classes</h3>
<p>Not all concrete API classes are intended to be instantiated by just
anyone. API classes have an instantiation contract indicating the terms
under which instances may be created. The contract may also cover things
like residual initialization responsibilities (for example, configuring
a certain property before the instance is fully active) and associated
lifecycle responsibilities (for example, calling <tt>dispose()</tt> to
free up OS resources hung on to by the instance). Classes that are
designed to be instantiated by clients are explicitly flagged in the
Javadoc class comment (with words like "Clients may instantiate.").</p>
<ul>
<li><b>Restricted instantiators.</b> Do not instantiate an API
class that is documented as available only to certain parties unless
you're one of them. In some situations, classes need to be part of the
public API for the benefit of a certain party (often internal);
instantiating one of these classes incorrectly has unspecified (and
perhaps unpredictable) consequences.</li>
</ul>
<h3>Subclassing platform API classes</h3>
<p>Only a subset of the API classes were designed to be subclassed. API
classes have a subclass contract indicating the terms under which
subclasses may be declared. This contract also covers initialization
responsibilities and lifecycle responsibilities. Classes that are
designed to be subclassed by clients are explicitly flagged in the
Javadoc class comment (with words like "Clients may subclass.").</p>
<ul>
<li><b>Restricted subclassers.</b> Do not subclass an API class
that is not intended to be subclassed. Treat these classes as if they
had been declared final. (These are sometimes referred to as "soft
final" classes).</li>
</ul>
<h3>Calling protected API methods</h3>
<p>Calling inherited protected and public methods from within a subclass is
generally allowed; however, this often requires more care to correctly
call than to call public methods from outside the hierarchy.</p>
<h3>Overriding API methods</h3>
<p>Only a subset of the public and protected API methods were designed to
be overridden. Each API method has a subclass contract indicating the
terms under which a subclass may override it. By default, overriding is
not permitted. It is important to check the subclass contract on the
actual method implementation being overridden; the terms of subclass
contracts are not automatically passed along when that method is
overridden.</p>
<ul>
<li><b>Do not override a public or protected API method unless
it is explicitly allowed.</b> Unless otherwise indicated, treat all methods
as if they had been declared final. (These are sometimes known as "soft
final" methods). If the kind of overriding allowed is:</li>
<ul>
<li>&quot;<b>implement</b>&quot;
- the abstract method declared on the subclass must be implemented
by a concrete subclass</li>
<li>
&quot;<b>extend</b>&quot; - the method declared on the subclass must invoke the method on the
superclass (exactly once)</li>
<li>
&quot;<b>re-implement</b>&quot; - the method declared on the subclass must not invoke the method on
the superclass</li>
<li>
&quot;<b>override</b>&quot; - the method declared on the subclass is free to invoke the method
on the superclass as it sees fit</li>
</ul>
<li><b>Ensure postconditions. </b>Do ensure that any
postconditions specified for the API method are met by the
implementation upon return.</li>
<li><b>Proactively check preconditions. </b>Do not presume that
preconditions specified for the API method have necessarily been met
upon entry. Although the method implementation would be within its
rights to not check specified preconditions, it is usually a good idea
to check preconditions (when feasible and reasonably inexpensive) in
order to blow the whistle on misbehaving callers.</li>
<li><b>Null result. </b>Do not return null as a result from an API
method unless the result is explicitly documented (on the specifying
interface or superclass) as allowing null.</li>
<li><b>Return copies. </b>Do not return an irreplaceable array,
collection, or other mutable object as the result from an API method.
Always return a copy to avoid trouble from callers that might modify
the object.</li>
</ul>
<h3>Implementing platform API interfaces</h3>
<p>Only a subset of the API interfaces were designed to be implemented by
clients. API interfaces have a contract indicating the terms under which
it may be implemented. Interfaces that are designed to be implemented by
clients are explicitly flagged in the Javadoc class comment (with words
like "Clients may implement."). A client may declare a subinterface of
an API interface if and only if they are allowed to implement it.</p>
<ul>
<li><b>Restricted implementors.</b> Do not implement an API
interface that is documented as available only to certain parties
unless you're one of them. In many situations, interfaces are used to
hide internal implementation details from view.</li>
</ul>
<h3>Implementing public API methods</h3>
<p>See "Overriding API methods".</p>
<h3>Accessing Fields in API classes and interfaces</h3>
<p>Clients may read API fields, most of which are final. Certain
struct-like objects may have non-final public fields, which clients may
read and write unless otherwise indicated.</p>
<ul>
<li><b>Null fields.</b> Do not set an API field to null unless
this is explicitly allowed.</li>
</ul>
<h3>Casting Objects of a known API type</h3>
<p>An object of a known API type may only be cast to a different API type
(or conditionally cast using instanceof) if this is explicitly allowed
in the API.</p>
<ul>
<li><b>Cast and instanceof.</b> Do not use instanceof and cast
expressions to increase what is known about an object beyond what the
API supports. Improper use exposes incidental implementation details
not guaranteed by the API.</li>
</ul>
<p>And, of course, casting any object to a non-API class or interface is
always inappropriate.</p>
<h3>Not Following the Rules</h3>
<p>Whether done knowingly or unwittingly, there are consequences for
transgressing the rules. It might be easier for all involved if there
were API police that would bust you for breaking the rules. However,
that is not the case. For the most part, API conformance operates as an
honor system, with each client responsible for knowing the rules and
adhering to them.</p>
<p>The contracts on the API elements delimit the behavior that is
supported and sustained. As the Eclipse platform matures and evolves, it
will be the API contracts that guide how this evolution happens. Outside
of these contracts, everything is unsupported and subject to change,
without notice, and at any time (even mid-release or between different
OS platforms). Client code that oversteps the above rules might fail on
different versions and patch levels of the platform; or when run on
different underlying OSes; or when run with a different mix of
co-resident plug-ins; or when run with a different workbench
perspective; and so on. Indeed, no one is even particularly interested
in speculating exactly how any particular transgression might come back
to bite you. To those who choose to ignore the rules, don't say that you
weren't warned. And don't expect much more than a sympathetic "Told you
so."</p>
<p>On the other hand, client plug-in code that lives by the above
rules should continue to work across different versions and patch levels
of the platform, across different underlying OSes, and should peacefully
co-exist with other plug-ins. If everyone plays by the rules, the
Eclipse platform will provide a stable and supported base on which to
build exciting new products.</p>
</div>
<div class="notices"><p>Java and all Java-based trademarks and logos
are trademarks or registered trademarks of Sun Microsystems, Inc. in the
United States, other countries, or both.</p></div>
</body>
</html>
content/articles/Article-Accessibility/about.xml 0 → 100644
View file @ da0077de
<article link="index.html">
<title>Designing Accessible Plug-ins in Eclipse</title>
<date>May 20, 2003</date>
<category>Plug-ins</category>
<category>Accessibility</category>
<author>
<name>Tod Creasey</name>
<company>IBM</company>
</author>
<update>
<date>July 25, 2006</date>
<reason>for Eclipse 3.2</reason>
</update>
<description>
Accessibility for disabled users is now a priority in
application development as advances in techniques and support
within operating systems have now made this possible. This
article covers the Eclipse accessibility support, general tips
for creating accessible plug-ins, and the types of disabilities
that the Eclipse accessibility support assists. This is all
illustrated using an example of making a view accessible.
</description>
</article>
\ No newline at end of file
content/articles/Article-Accessibility/images/Idea.jpg 0 → 100644
View file @ da0077de
content/articles/Article-Accessibility/images/Idea.jpg

4.98 KiB

content/articles/Article-Accessibility/images/accessibility.gif 0 → 100644
View file @ da0077de
content/articles/Article-Accessibility/images/accessibility.gif

12.9 KiB

content/articles/Article-Accessibility/images/appearance.gif 0 → 100644
View file @ da0077de
content/articles/Article-Accessibility/images/appearance.gif

4.12 KiB

content/articles/Article-Accessibility/images/beforescreen.gif 0 → 100644
View file @ da0077de
content/articles/Article-Accessibility/images/beforescreen.gif

9.06 KiB

content/articles/Article-Accessibility/images/default_style.css 0 → 100644
View file @ da0077de
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}
.corner { color: #FFFFFF; font-weight: bold; }
\ No newline at end of file
content/articles/Article-Accessibility/images/error_tsk.gif 0 → 100644
View file @ da0077de
content/articles/Article-Accessibility/images/error_tsk.gif

169 B

content/articles/Article-Accessibility/images/finalview.gif 0 → 100644
View file @ da0077de
content/articles/Article-Accessibility/images/finalview.gif

8.73 KiB

content/articles/Article-Accessibility/images/fixedcolors.gif 0 → 100644
View file @ da0077de
content/articles/Article-Accessibility/images/fixedcolors.gif

6.97 KiB

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