Community
Participate
Working Groups
There has been discussion around the naming/positioning of the elements in the Helios repository intended to be added to people's target platforms. In the past teams have contributed "SDKs" to the EclipseRT Target Platform Components category. This has caused confusion as many people in the community think of SDKs as something that gets installed into the IDE. In an effort to clarify the situation for users the RT PMC decided that the elements of the EclipseRT Target Platform Components category in the Helios repo should appear as XXX Target Components So, for example, "EMF Target Components", "RAP Target Components" etc. This gives clarity to the consumers and accurately positions the elements as something that is used to compose a target platform. We ask that projects contributing to the Target Platform category in Helios change the *name* of their contributed features as soon as possible so that the RC repos can be tested for consistency. NOTE that you do NOT have to change the feature ID or feature structure, just the human readable feature name (likely in the feature.properties files)
I have a couple of questions/concerns about this request: 1. Our EMF SDK feature is currently included in two categories - the Modeling one, where it makes sense to call it an SDK, and the runtime target one. We obviously can't give the feature two names. 2. What do we do about "runtime" features vs. those that include source (currently the "SDK")? Do we include two features in the runtime target category, e.g., one called "EMF RAP Target Components" and one called "EMF RAP Target Components with Source" (or something like that?).
> 1. Our EMF SDK feature is currently included in two categories - the Modeling > one, where it makes sense to call it an SDK, and the runtime target one. We > obviously can't give the feature two names. If the names need to be different then yes, you likely have to have different features. I do wonder though if Target Components would not satisfy both viewpoints. Unless there is more in your "SDK" than I am thinking? Is there tooling in there? Why would someone install it in to their IDE explicitly? > 2. What do we do about "runtime" features vs. those that include source > (currently the "SDK")? Do we include two features in the runtime target > category, e.g., one called "EMF RAP Target Components" and one called "EMF RAP > Target Components with Source" (or something like that?). you can/should have as many runtime features as your user community needs/wants. Gather these and the relevant source features together and include them in *the* EMF Target Components feature and you are done. Think of the Target Components feature as a simple delivery mechanism akin to a zip file. User says "ughh, want EMF. uggghh, EMF Target Components. ugghh, good." No fuss, no muss, no questions or decisions. ugggghhh...
(In reply to comment #2) So this no longer amounts to just changing the name of one or more of our features. ;) Since it's probably too late in the game to start introducing new features, I propose that we change the names of the EMF RAP features (currently referred to as "runtime" and "SDK") to the following: EMF RAP Target Components EMF RAP Target Components with Source I could see folks using one set of target components (the one with source) during development and then switching to a different set (the one without source) for production. I suggest we remove the "normal" EMF SDK feature from the runtime components category (since both the EMF "runtime" and "SDK" currently contain tools) for this release and consider adding additional features for the next release, which might include things like "EMF RCP Target Components" and "EMF GWT Target Components".
(In reply to comment #3) > So this no longer amounts to just changing the name of one or more of our > features. ;) Depends on what you want to do. > Since it's probably too late in the game to start introducing new features, I > propose that we change the names of the EMF RAP features (currently referred to > as "runtime" and "SDK") to the following: > > EMF RAP Target Components > EMF RAP Target Components with Source The main point of this bug is to end up with one (small number) of features that we can put in the Target Platform Components category in the Helios repo. That feature(s) can contain any number of other features you want. So, to that end, I suggest EMF RAP Target Components - includes EMF RAP Support - includes Source for everything in the feature - includes <whatever other runtime features you think people will want> The important point here is that no user should likely ever think that a feature called * Target Components is something that they should ship in their production system. It is just a "random" collection of stuff that the producers thought would be interesting/useful for people to download. The real runtime breakdown of the function should be included as features inside the Target Components feature. Stepping back a little, what is special about the RAP target components feature vs normal EMF SDK vs. an EMF RCP feature? Can these all be combined into one EMF Target Components feature that comes with RAP, RCP, ... support? Remember, this feature is NOT what people are expecting to ship for productino. It is what they are using to populate their target at dev time. > I suggest we remove the "normal" EMF SDK feature from the runtime components > category (since both the EMF "runtime" and "SDK" currently contain tools) for > this release and consider adding additional features for the next release, > which might include things like "EMF RCP Target Components" and "EMF GWT Target > Components". While it is not my place to tell you how to present your function to your consumers, I personally use the EMF SDK feature in creating my target platforms so would miss it if you removed it. While having some tools in it is unfortunate, it is not the end of the world. It likely means that people adding it to their target platform should turn off dependency following or risk getting bloated targets. Ultimately, your target components feature should contain whatever you think your community would need/want.
(In reply to comment #4) OK, then we'll go with "EMF RAP Target Components" for Helios. This will be the new name for the feature previously called "EMF RAP SDK". We can't include these components in the same feature as target components for RCP since the two cannot co-exist in a single target platform. I don't think it makes sense to continue to include the "normal" EMF SDK in the runtime category (since we can't rename it), but it can still be found in the 'Modeling' category and installed into a target platform for those that want to.
(In reply to comment #5) > OK, then we'll go with "EMF RAP Target Components" for Helios. This will be the > new name for the feature previously called "EMF RAP SDK". We can't include > these components in the same feature as target components for RCP since the two > cannot co-exist in a single target platform. Great. Thanks > I don't think it makes sense to continue to include the "normal" EMF SDK in the > runtime category (since we can't rename it), but it can still be found in the > 'Modeling' category and installed into a target platform for those that want > to. There is considerable interest in positioning EMF in the runtime space (from both the producer and consumer side). I would rather hold my nose and have the EMF SDK show up in the target platform components category than have EMF be absent altogether. Does that work for you?
(In reply to comment #6) > (In reply to comment #5) > > OK, then we'll go with "EMF RAP Target Components" for Helios. This will be the > > new name for the feature previously called "EMF RAP SDK". We can't include > > these components in the same feature as target components for RCP since the two > > cannot co-exist in a single target platform. > > Great. Thanks > > > I don't think it makes sense to continue to include the "normal" EMF SDK in the > > runtime category (since we can't rename it), but it can still be found in the > > 'Modeling' category and installed into a target platform for those that want > > to. > > There is considerable interest in positioning EMF in the runtime space (from > both the producer and consumer side). I would rather hold my nose and have the > EMF SDK show up in the target platform components category than have EMF be > absent altogether. Does that work for you? OK, we'll leave the SDK in there for now. Next release, we can replace it with a more appropriate target components feature. The changes (to the EMF RAP features) have been committed to CVS.
Closing all fixed releng bugs.
