Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Architecture Council Discovery and Reuse Activity
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.