SDK Composition

During the last Planning Council meeting, the topic of SDK composition was discussed (again). Historically, there has been no definition of SDK or prescribed content. This wiki page hopes to start the discussion of how to solve this issue in order to make the consumption of Eclipse projects more consistent, particularly for the simultaneous release train. The current inclination for Galileo is to provide an end-user categorization of capabilities, along with a separate SDK categorization for advanced users.

The goal of this page is to provide a standard definition of how to compose, package, and deliver project SDKs to facilitate their consumption from Galileo and subsequent release trains.

Definition of SDK

• The Eclipse SDK includes the platform, cvs, jdt, pde, and pde.p2 features, along with their respective source features. It also includes the SDK branding plug-in. Documentation including JavaDoc is included. Samples are not included in the download, but can be downloaded and installed via the Welcome page.
• The EMF SDK includes sources and docs, but no examples. GMF and GEF provides examples, but only those that are extracted into the workspace so as not to pollute the UI with example contributions. WebTools has examples, but distinguishes between those that are used in the context of developing web applications and those which are in the context of extending WebTools itself.
• The Eclipse project provides a single SDK that includes several major features, as listed above. GMF provides a single SDK to cover both tooling and runtime, with an additional SDK for "experimental" features. What is the proper granularity of SDK to provide? Per major feature or component?

These are just some examples (feel free to add additional) of how the definition of SDK differs among projects. Part of the problem lies in the fact that some projects are only frameworks (e.g. GEF) while others deliver end-user tooling (e.g. JDT), while both may be extended. So when considering as part of delivering Galileo what is runtime and what is SDK, the answer is invariably, "it depends."

The Planning Council concluded that for Galileo, the initial categorization of capabilities provided would focus on end-users and deliver SDKs separately, which gives us some time to agree upon SDK definition and makeup. The general consensus was that an SDK includes:

• Source code
• API and extender documentation
• Examples which extract into the workspace, or which have capabilities defined such that they can be hidden

Known Issues

• The welcome page samples used by the platform utilize non-API functionality that would be helpful to other projects if made API. Is this planned? Promotion of a standard manner by which to download/extract samples would help bring consistency in their packaging.
• The Eclipse SDK branding plug-in contains UI contributions and other functionality that would be best extracted (e.g. Capabilities preference page contributions). In other words, SDK features should be delivered without additional functionality beyond source code, javadoc, and examples). Part of the complication here as well is that the SDK branding plug-in also serves as the product contribution plug-in. Perhaps SDK features should be included by product features/plug-ins and not combined?
• SDKs typically have javadoc that references dependency javadoc, begging the question of whether SDK features should directly reference dependency SDK features? This would simplify SDK installation, though raises the SDK granularity question from above.