Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Architecture Council Discovery and Reuse Activity

Revision as of 21:25, 13 December 2006 by Ohurley.iona.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Introduction

The Eclipse Ecosystem is a big place, and within it there are a many projects each of which may have many APIs, extension points and interesting functional elements. One of the key advantages of being part of the Ecosystem is the fact that there is a lot of work already available that can help you add greater value to your project at a relatively small cost. We are talking reuse here, but the one part of the equation that is difficult to work out is the process of discovering what functionality is available as a re-usable component.

The Architecture Council recognizes that the ability to re-use existing components is a powerful means to add value to any project. So, at the last AC face to face in Stuttgart , an activity was given the go-ahead to address some of the issues that currently challenge this re-use. This is the Discovery and Reuse Activity.

The Activity

Our proposal is that the initiative should commence with the population of a catalog of functional elements that can be searched on function and project. This will aid in the discovery process when an existing or proposed project wishes to first confirm that a function is not already catered for within the bounds of the existing ecosystem.

Initially, the catalog will be based upon components that have a public, supported API. This incorporates extension points of projects and other facilities that may be exported by plugins. This information should be made available by the project that is hosting/supporting the APIs.

In future, it should be possible for an interested third party to indicate that a functional element of a project, which may be represented solely as an internal API, would be a suitable candidate for re-use. To give potential consumers a clearer vision into the functional elements of a project, it may be useful to have the project document in minor detail important internal APIs.

Contributions to the catalog should be made by the projects themselves, and initially the catalog may be hosted as multiple wiki pages. In future, the catalog should be browsable and searchable from a central place.

The DTP and STP projects have posted exemplar catalog pages at DTP Component Catalog and STP Component Catalog, respectively. These are starting points to get your feedback on content and form. We fully expect that the explanatory items associated with each re-usable component will undergo some changes as the approach is refined.

Your feedback is actively solicited. Please address your comments to the Architecture Council.

Back to the top