Community
Participate
Working Groups
At the January 23rd Planning Council meeting (http://www.eclipse.org/org/councils/20070123PCMinutes.php) we decided to name the Europa features "extender" and "end-user". From the minutes: Europa SDKs and Run-times The main issue here is that "SDK" means different things for different projects. In the end we concluded that there are at least three different things: (1) run-time, (2) tooling, (3) extender kit. Not all projects have all three. The run-time is like the VM for the project - consider the EMF run-time: there's no tooling and it is just what is needed to execute an EMF model. However, the Platform run-time distro does include tooling: the basic Eclipse IDE tools. (Hence confusion over the wording) The tooling distro of a project includes the run-time (to run the tools), end user tools, and end user documentation. The extender kit for each project is the tooling disto plus that which is required to extend the underlying frameworks. Also known as an SDK, the extender contains source code, adopter documentation, examples, etc. We decided that the extended kit SHOULD include an explanation (in the help system) of how to get the examples for the project although the examples do not necessarily have to be included with the kit. This is often useful because the examples should be installed the developer's workspace instead of in the Eclipse instance itself and the Eclipse distro mechanism can only install to the instance. The Council decided that each Europa project will have two entries in the feature list: an "end-user" feature and an "extender" feature. The Council further decided that each project will distribute it's pure run-time separately from the main Europa update site. Here we are taking the position that the Europa update site is for end-users and not as a substitute for the project-specific download pages for project-specific things (such as project-specific run-times/VMs). ACTION: [all] Update the wiki page to explain whether your project will include examples as part of the extender version. ACTION: [all] Update your project's features to include the words "end-user" and "extender". On the February 7th Europa call, this issue was reopened for discussion. I've opened this bug to record the conversation.
For projects who have just one feature each, this should be easy e.g. "CDT end-user kit" vs. "CDT Extender Kit". For projects who have a fine granularity of end-user features, it is confusing to add the term "end-user" to most of the feature names. What about renaming the SDK to "extender kit" and leaving the runtime/end-user features untagged? Another idea mentioned during the call was to improve update manager to allow more than 1 level of categories. Then, for projects who have many features on Europa and don't want to rename them all, below the current categories there could be categories for "End-User Kits" and "Extender Kits" and below these additional categories there could be the current feature names.
In my experience it is difficult to target a single update site at both users and integrators: * Most update site consumers are users, and there is a cost to overwhelming them with integrator features, forcing them to understand the difference between the two, and having them make complex disjoint selection. * Integrators are more sophisticated, probably don't mind going to an alternate update site, and just want an easy way to get runtimes and sources for a few frameworks of interest. I haven't thought this dual-site scenario through enough, so would be interested in hearing downsides. A question about the naming: I though we called the people extending our frameworks "integrators". Is this changing to "extenders" or "adopters"? I don't like "adopters" because some end users think of themselves that way. "Integrators" seems a bit more accurate than "extenders" because some people simply embed a framework, but I can see the rationale for the latter.
EMF's "runtime" actually includes tools, so as of today (bug 173343) I've renamed the features as they'll appear in Europa (and the next Callisto, too). EMF SDK Feature (contains 9 subfeatures): http://dev.eclipse.org/viewcvs/indextools.cgi/org.eclipse.emf/plugins/org.eclipse.emf-feature/org.eclipse.emf.sdk/feature.properties?view=diff&r1=text&tr1=1.8&r2=text&tr2=1.10&diff_format=h EMF Runtime Feature (just one feature): http://dev.eclipse.org/viewcvs/indextools.cgi/org.eclipse.emf/plugins/org.eclipse.emf-feature/feature.properties?view=diff&r1=text&tr1=1.12&r2=text&tr2=1.10&diff_format=h You'll notice they also include "extender" and "end-user" as applicable. Since thee distinction between these two features is now based on role, not contents, I've also rewritten the descriptions to speak to the 'if you're a user who...' question, rather than 'this feature contains...' question. I spoke with Christian Damus after this change about his OCL features and he's going to create a composite-runtime feature - sorry, "end-user" feature - which will bundle his other runtimes into a single Europa offering, in parallel with his existing SDK ("extender"), which will contain the same + docs and source.
So far, we have categories for subject matter, such as "Modeling", "Web Development", and "Enabling Features". We can use these to categorize the run-time features for end-users to discover them easily. Perhaps we can also add, at the end of the list, an "Extender Kits" (I like Martin's name for it) category that includes all of the SDK (extender) features? Ideally, this category would be subcategorized according to the end-user categories, but if we don't get that from the update manager in time, at least all of the SDKs will be out of an end-user's sight but still accessible to power users. As Nick mentioned, I will be looking into aggregating my many run-time features into a smaller number of end-user features especially for Europa. For example, EMFT-QTV has 6 run-time features all providing functionality for model integrity, so I would group them as an "EMF Model Integrity Frameworks" end-user/extender feature pair. Similarly for the several features of MDT OCL. This may depend on the ability of update manager to present N levels feature nesting (as opposed to category nesting); I'll give it a try.
Thanks a lot Nick for posting the examples. I've updated our feature.properties for dsdp.tm. What's sort of special with us is, that we have three pretty small features. Typically, these are "glue" features which integrate our offering with some other: They need to be separate features, because update manager doesn't like it if the "glue" feature is installed but the required "other" feature is not. Example: "rse-remotecdt" requires features "rse" and "cdt", and it must be separate because we need to support the possibility of running rse without cdt or cdt without rse. For these small features, we don't currently do separate extender and user kits, but simply ship one which happens to include sources (and may include isv docs some time). We figured that end-users wouldn't care about the extra few KBytes. What do you folks think about this approach? Example: # "featureName" property - name of the feature featureName=CDT Remote Launcher End-User and Extender SDK # "description" property - description of the feature description=A Launch Configuration for debugging C/C++ programs on a \ remote host through RSE-provided shell and file services, and gdbserver. \ Includes Source.
Nick had previous sent me an email where he said: "Or, alternatively, you could create two update sites, one for Europa Lite Edition (runtimes only: "Works great, less filling!") and one for Europa Extreme Edition (SDKs)."
(In reply to comment #6) This approach would require one of two things to implement: a) we publish TWO sets of feature-*.xml files, and you collect the runtimes-only ones into one /updates/ site, and the sdks-included ones into a second /updates/ site. -- More work for us releng folks: more scripting for me (to support creating two files instead of one for the Modeling project), more manual labour for many (duplicated effort in many cases, I'm guessing, for those who update these files by hand). b) we provide both sdks and everything else in one set of feature-*.xml files (as we do today), and you revise the Bjorn-o-matic to create two update sites by filtering on "sdk" or "extender" or a set of regular expression matches. ++ More work for you: one-time scripting change to support both modes of update site generation. In either case, I like the "lite" and "extreme" names, as they line up very nicely with the common names for the available bandwidth bundles used by my local phone/cable ADSL providers. (They're not as good at describing contents ("runtime", "framework", "tooling", "stand-alone", "SDK") or role ("end-user", "adopter", "developer" "extender") but they certainly do describe required bandwidth.)
(In reply to comment #6) > "Or, alternatively, you could > create two update sites, ... My intuition is that two sites shouldn't be used. I'd suspect a prime use case is that many users would want to get all (or most) of Europa end-user packages, and, at the same time, get a few of the packages they might be extending. Also, I think the main purpose of the Europa update site is to be a one-stop "discovery" site ... where users can see and download things they maybe haven't used before, so ... having multiple sites seems to lessen the "one stop shopping" convenience.
(In reply to comment #7) > b) ... More work for you: Not a problem - I will support whichever situation the team agrees upon.
(In reply to comment #8) > My intuition is that two sites shouldn't be used. I'd suspect a prime use case is that many users would want to get > all (or most) of Europa end-user packages, and, at the same time, get a few of the packages they might be extending. But don't we have at least an order of magnitude more people using Eclipse-based than extending on Eclipse-based frameworks. This would imply that making a one stop-shop for everyone burdens the majority with understanding and picking away the SDK things they don't need. A substantial number of users wouldn't bother and would just install everything anyway, both lite and extreme bits. Or is the Europa site being targeted at "advanced users and integrators"? In that case the single site approach seems fine, but I think that should be stated explicitly.
(In reply to comment #5) After further consideration and checking what it actually looks like on the Europa M5 Staging Site, I think that for those of our small features which are both end-user and SDK kit in one (because they include sources), I'll get rid of the "end-user and extender SDK" specification. It's simply confusing, and if there is only one variant, everybody is clear that it's what they need, regardless of whether they are end-users or extenders. Examples: "Remote System Explorer End-user Runtime" "Remote System Explorer Extender SDK" "Remote System Explorer C/C++ Remote Debug Launcher" "Target Management Terminal" The description of those features will then say "... includes developer documentation and source." See also bug 175245. BTW, with respect to having one or two sites, I agree that there should be only one. Managing dependencies between the two would be a headache otherwise. I actually do like the current Europa M5 Staging site pretty much, so perhaps it's all going to sort out well with what we currently have.
When I prepared my laptop for EclipseCon today, I wanted to install runtimes of most Europa projects just to try them out. Doing so, I found a major limitation of the current site layout - usually, I would have liked to just click on, say, category TPTP in order to get all runtime variants of TPTP. But knowing that this would also give me the SDKs (adding downloads and disk space I don't want), I had to expand each of the categories and manually select runtimes vs. SDKs. This is not user-friendly at all. When I'm not mistaken, many projects provide a more fine-granular selection of runtimes and a more coarse-granular selection of SDKs (e.g. select from 4 runtime components, but 1 SDK includes them all). So what about a site.xml category layout like this: * Category names as we have them now, for all the runtimes * ONE additional category named "Extender SDKs" holding all the SDKs This would account for most users just getting the runtimes (and allowing them to click on the category to get all), whereas those who want an SDK just go to the SDK category -- they will typically want to develop against ONE SDK only, so selecting from the single category should be OK. Comments?
+1 for the single Extender SDKs category. That has much of the benefit of the alternative update site proposal without its severe limitations.
(In reply to comment #12 and comment #13) +1: simple yet effective, solves both the need to split SDK from runtime and the need to have everything in one site.xml
+1 for the single Extender SDKs category, reasoning from comment#2: > * Most update site consumers are users, and there is a cost to overwhelming them with integrator features, > forcing them to understand the difference between the two, and having them make complex disjoint selection.
Since we decided not to require SDKs in Europa, this bug is moot. Closing.
.
