| [eclipse.org-architecture-council] On runtime, SDK and tooling features |
This message is background material and a proposal for the eponymous discussion topic for tomorrow's call. It is relevant to any project that delivers a runtime (i.e., non-tooling) element. It talks about how we deliver those elements in a consistent way with the main goal of easing developer discovery and consumption of those elements. I apologize for the length but there are a great many issues and elements and a great deal of confusion about them. Jeff We have found it convenient to collect up and deliver sets of bundles in features. While not always true, we'll assume the use of features in this discussion. In the runtime space we have the triple challenge of delivering 1) the runtime bits (bundles and features) in a form that is easily composable into further features and products 2) the development time (SDK) bits (e.g., runtime bits, plus source etc) that developers need when crafting their bundles 3) the tooling (if any) associated with the runtime Tooling is, well, tooling. Tooling features get installed in the IDE and used by the developer. We are good at this though there are some gotchas. See below... Runtime and SDK features are more subtle. Runtime features talk about the runtime bits that people compose (put together) to create a runnable system (e.g., launch configs or products). SDK features talk about the bits needed to create a developable system (e.g., Target Platform). They differ in that at development time you need source to aid debugging and coding workflows. You may also need some additional bundles to compile against or mock facilities not normally available. These are not things you would ship in a running application, they are the raw materials you needed to make the application. It is critical that we not confuse these three types of feature as their audiences and destinations are different. Lets look at why. IDE independence: Some projects have been shipping their runtime bits in the IDE. Sometimes this is needed for the actual functioning of the tools. Fair enough. Where it is not, they have been leveraging a quirk of PDE that has the default Target Platform set to be the IDE itself. Convenient but this clearly does not scale (should we put all runtimes in the tools?). And what happens when the tooling changes? That changes the target platform and workspaces suddenly don't compile any more. Actually, this happened recently when one project had to remove some "unnecessary" runtime bits from it IDE contribution. In the runtime context, using the IDE as your target is "a bad thing". Ease composition: Eclipse use scenarios are ever evolving. You as project teams know your domain and community best and should decide what configurations of your function (i.e., features) makes it easiest to consume when defining runtime configurations. These choices should be independent of any tooling or SDK concerns. Apparent complexity: Choice is not always a good thing. The first point of entry to using your technology is your download or contribution to the repo categories. As a consumer, which is more attractive, a list of one, "Equinox SDK" or a list of more than 8, "Equinox Core, Server Jetty, Server Simple, Security, Compendium, p2, ..." Imagine having to download 8 zips just to get started with Equinox! Or worse, thinking that you have to choose which of the 8 you need! Availability: GEF is one of the most useful projects at Eclipse IMHO yet it has never surfaced in the release repo categories. Why? Because we have never distinguished between the different kinds of features and have typically only categorized user tools with no place for the others. These key factors (and others) should drive the definition of the EclipseRT release contributions and repo categorization. Concretely, they manifest as the following guidelines: - EclipseRT projects should define a set of runtime bundle groupings (e.g., features) to ease the composition of their technology into runnable solutions. If everyone needs bundles A, B, E, and R then make a feature so folks just add the feature to their product/launch config rather than having to know the list. - EclipseRT projects must have 1 (at most 2) SDK features categorized in the Target Platform category in the release repo. More than that you are saying "we are complex and you have to understand a lot just to start even looking at our function". Less than that and well, you are not there at all so, why bother being in the release? - Projects with SDK features should make available downloadable zips that have at least the same content as the transitive closure of the *inclusions* for their SDK features. Simply put, export your SDK features into a zip as a p2 repo and put it on a download page. This enables offline scenarios etc. - Tooling projects and EPP packages must NOT include random stuff with the assumption that it will automatically be picked up in the Target Platform. This just bloats and causes issue as mentioned above. |