Bugzilla – Full Text Bug Listing
| Summary: | no capabilities if just "runtimes" installed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | David Williams <david_williams> | ||||
| Component: | UI | Assignee: | Tod Creasey <Tod_Creasey> | ||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P5 | CC: | bokowski, David.Olsen, eos.eclipse, for.work.things, gunnar, gvaradar, jeffmcaffer, jpetrakis, manahan, mark.melvin, Mike_Wilson, panagiotis.korros, pascal, philippe_mulet, snorthov, stephen.francisco, villane, warren.paul | ||||
| Version: | 3.2 | Keywords: | helpwanted | ||||
| Target Milestone: | 3.3 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
David Williams
No they are defined in the org.eclipse.sdk plug-in so how is this "works for me"? Users should be able to just install the runtimes, and still have capabilities. What am I missing? After giving this more thought, I do not see any alternative but to re-open. And, it "blocks" capabilities from working in WTP, if only runtimes installed, since ours (e.g. j2ee) are based on those from the Eclipse Project (e.g. Java). And, it somehow seems obvious to me that capabilities need to be present, even if "source" is not desired to be installed. So ... I think some refactoring needs to be done and some new plugins/features added to seperate "source" from the product plugin. The biggest (only?) hurdle to overcome is to be sure that the "product definition plugins" (which includes capabilities/activities) can still be installed or not installed by adopters, since, its my understanding, that adopters are to be able to "redefine" their own capabilities as they desire. You are missing the SDK plug-in where we define these. You will need to define yours in a plug-in that has a dependency on the SDK. We would not move them into other plug-ins because it makes it much harder to build applications that are not based on the SDK if you are forced to absorb our sdk level definitions. Likely the best solution for you is to create a plug-in that is dependant on our sdk (assuming you don't have one already) and then WTP users who want your capabilities can use it and remove it if they don't. I use WTP at home for my websites and would never need capabilities as I run with a smallish subset of the SDK. (In reply to comment #4) > > Likely the best solution for you is to create a plug-in that is dependant on > our sdk (assuming you don't have one already) and then WTP users who want your > capabilities can use it and remove it if they don't. Yes, but, I think we need to be able to do this at a feature level. Using current features ... say, via update manager, ... users would *have* to install all source from the platform, jdt, and pde, inorder to get capabilities. > > I use WTP at home for my websites and would never need capabilities as I run > with a smallish subset of the SDK. Glad to hear you are using WTP :) I never use capabilities either (leave all "on"), but one of the goals of Callisto to to allow those users (who are more casual than you and I) to install everything, but not be burdened by things they do not need ... at least until they say they want that capability. The sdk plug-in only depends on ui, cheatsheets and help. I'm not clear why you need JDT and PDE. (In reply to comment #6) > The sdk plug-in only depends on ui, cheatsheets and help. I'm not clear why you > need JDT and PDE. > I'm refering to features. Your current structure is like ==Current== below. Note, there's nothing I can install via update manager, to get capabilities. What I'm suggesting is a restructuring, similar to ==Proposed== below, so that capabilties can be installed with runtimes (and, still, easily ignored, or "left out" by adopters who re-define your capabilities). (The indents below, signify and "includes" relationship in PDE Feature terms). == Current == f/org.eclipse.sdk p/org.eclipse.sdk f/org.eclipse.jdt.source f/org.eclipse.jdt f/org.eclipse.pde.source f/org.eclipse.pde f/org.eclipse.platform.source f/org.eclipse.platform f/org.eclipse.rcp.source f/org.eclipse.rcp == Proposed == f/org.eclipse.runtime f/org.eclipse.product f/org.eclipse.jdt f/org.eclipse.pde f/org.eclipse.platform f/org.eclipse.rcp f/org.eclipse.product (new) p/org.eclipse.product (this is what is now called "org.eclipse.sdk"). f/org.eclipse.sdk f/org.eclipse.runtime f/org.eclipse.jdt.source f/org.eclipse.pde.source f/org.eclipse.platform.source f/org.eclipse.rcp.source Created attachment 36145 [details]
Suggested runtime feature
If I am not mistaken the issue here is that you want to load the sdk plug-in without loading the whole world.
Here is a suggested feature that refers to the sdk plug-in. By just adding this feature your runtime situation should be taken care of as it does not load the other features the sdk feature requires.
while this solves the "not installing everything" problem, I think using the plugin with a name of 'sdk' is a bit confusing, as its not 'sdk' in most definitions of the word (that is, no 'source' associated with it). I am not tied to any particular name. If this is a satisfactory solution to your problem I'll bring it up at the architecture meeting (it is always better if you have a solution in hand). In which download would the attach feature be provided? (In reply to comment #11) > In which download would the attach feature be provided? > Well, when you put it that way, maybe we are not there yet. The more I think about this, it seems each major component the contributes to a "product definition" (with capabilities, default preferences, etc)., should so so it with its own (new) plugin, thinly wrapped in a (new) component-product feature. Having a seperate plugin/feature pair is important so adopters could easily "leave out" if they wanted to redefine those product characteristics, without "carving up" features. I can draw a picture if needed, but the idea is the "component-product feature" would be "shipped with" the current runtime features for the existing components. That way, no matter how future users "mix and match" components to install, they will get the right product related stuff with the runtimes. So, so provide a picture for comment #12, I think a modified proposal would look as follows ... as Tod, I'm not strong on the names ... but this, I think, reflects correct componentiation. [I am also not sure if the "plain platform" (no pde or jdt) has any "product definition" ... if it did, it also would need a feature/plugin pair. == Proposed == f/org.eclipse.runtime f/org.eclipse.jdt.product f/org.eclipse.jdt f/org.eclipse.pde.product f/org.eclipse.pde f/org.eclipse.platform f/org.eclipse.rcp f/org.eclipse.jdt.product (new) p/org.eclipse.jdt.product (this is "half" of what is currently "org.eclipse.sdk" -- capabilities, default perspective). f/org.eclipse.pde.product (new) p/org.eclipse.pde.product (this is "half" of what is currently "org.eclipse.sdk" -- capabilities). f/org.eclipse.sdk f/org.eclipse.runtime f/org.eclipse.jdt.source f/org.eclipse.pde.source f/org.eclipse.platform.source f/org.eclipse.rcp.source After talking at the arch meeting this morning we thought the change that would require the least structural changes was to add the org.eclipse.sdk plug-in to the WTP feature that required it and make no changes to our features. (In reply to comment #14) > After talking at the arch meeting this morning we thought the change that would > require the least structural changes was to add the org.eclipse.sdk plug-in to > the WTP feature that required it and make no changes to our features. > WTP? did you mean something else? I opened this bug from a callisto point of view. So if someone installed JDT runtimes and PDE runtime and other callisto type projects, but not WTP, they would still not have capabilities? At least not the java and pde ones? While I appreciate your consideration in getting WTP to work, I'm still not sure what I should do ... add it to a "requires" statement in our feature.xml? Then we (WTP) would simply not install from update manager, if SDK not present? Or ... did you mean for use to "repackage" it in our features, and use 'includes'? I understand it is a general Callisto issue - I was referring to WTP as you are the component that wants to deal with this first. The first question is about how you structure your features. Using the platform SDK features should likely be in a WTP sdk feature while the other plug-ins would be in a WTP runtime feature. If you want to use WTP as a lightweight addition to an rcp app you could just load the runtime feature. If you wanted sdk integration you would load the WTP SDK which would require the SDK plug-in. The sdk plug-in would need to be available from any site that hosts the WTP sdk feature. Marking as Remind as it appears there is nothing else to be done at the platform level Thanks for the prompt Tod. I assume putting it in 'remind' means you are waiting for input from me.
And my input is ... this is still badly "broken" ("bad" at least from a design or architecture level). And, I'm afraid I'm not getting my point across very well. So, let me try this:
Steps to reproduce:
Starting afresh, install anything you want from Callisto Discovery site.
Then try to find "PDE" and "Java" capabilities.
They are not to be found. They were not installed.
contrast this with unzippling "Eclipse sdk".
You do get PDE and Java capabilities.
My point is, there is nothing "sdk" related about "capabilities".
I know the terminology is hard .. "sdk" is used in many ways ... when I say "there is nothing sdk related", I mean there's nothing related to having source plugins or ISV docs available, that is related to having capabilities installed.
So, my question is, where do the "capabilties" go in the Callisto features?
I think by recommendation is still valid. (And, I know that seems like "a big change" at this point ... but, that's different than saying "nothing else to be done" :)
I'll leave it to you to decide how to proceed, or tell me that I'm missing your point :)
Recap: The main issue here is that the definition of capabilities has been thought of as a "product" thing. So the ones you get in the download are not "SDK" things but rather, "Eclipse SDK Product" things. The challenge with doing otherwise is a classic producer/consumer thing. If we put the capabilities in some plugin that was in some feature that is part of the regular Eclipse binary drops then everyone would get them whether they want them or not. Everyone appears to agree that this is an issue. We also seem to agree that an answer is to include what is now the org.eclipse.sdk feature in some form in features that do not bring in the whole world. I'm not a fan of creating a mess of features now to work around what is a more fundamental problem (in the way both features and capabilities work). The approach outlined in comment 8 appears to address the immediate issue and does not require new plugins. As for comment 11, I suggest that this plugin be listed in a new feature that is explicitly part of the callisto story. For example, what are WTP, BIRT and the others doing for this issue? Do they have the same problem? Perhaps we should just have a "capabilities feature" that includes capabilities plugins for all the elements of Callisto. Users could be directed to get this themselves or, perhaps, this feature could be added as an optional requires on the top level project features. Thanks Jeff. That helps, but I think there's more "immediate problem" here than you realize. I happen to know personally of some adopters that do not want to depend on installing the precise right versions of plugins for their product to work. That is, they'd like their users to be able to simply "pre-req" it, or, at least, to be able to install a new version "of the base" (or, of wtp). And have their product capabilities remain the same. So, bsides "splitting out" capabilities into their own feature, could they be combined with a runtime feature, but be "controlled" via the normal -product mechanisms? [And, before you ask, yes, I mean for 3.2 :) I know that's a lot to ask, but this, to me, seems like a "product breaking" problem ... and, the Callisto/WTP issues just happen to make them more apparent early ... as it should :) ] Thanks for your continued attention to this. re-reading some of these now (I was relying on memory too much) ... I did want to say, yes, the feature in comment #8 would be good. I'd still prefer a different name that doesn't include SDK ... and maybe this "selective activation" issue related to -product is a seperate bug/feature request? In regards to the recap in comment #19 about capabilities being a "product" thing. Right now, the only way it's considered a product definition is because it's in the product plugin. Anyone could stick a capability definition in their own plugin, and everyone would pick it up, right? Maybe an extra attribute or child tag should be added to the capability extension point to identify what product the capability should be associated with. The org.eclipse.ui.activitySupport extension point has this. Re comment 20. I'm not sure where the versioning comes into play. I was not proposing anything wrt precise versions. Re comment 22. When I talked about capabilities being a "product" thing I didn't really mean wrt the product plugin so much as they are akin to the product preference customizations. Product designers sit down and craft the user experience they want and encode it in, for example, a set of capabilities. That declaration, as you point out, can go in any plugin. The challenge here is that Callisto has no "product". My thinking in the previous comments was to say, "hey, the Callisto 'product' wrt capabilities is the union of all capabilities in its constituent parts" So just gather them all up, put them in a plugin, put the plugin in a feature put hte feature on the update site and there you go. I'm certainly not claiming it is a great solution but it would likely work. BTW, I did not see a summary of how WTP or any other project ships their capabilities. To answer Jeff's question, We in WTP put our capabilities in "product" plugins, and those are defined as part of a "runtime features". They are not broken out in seperate "product feature", but perhapss should be to allow adopter products to more easily omit them, and ship their own? (By "runtime", I just mean "minimal" install, no source, so "extenders" documentation .. just people who want to create web apps ... those users would still want "capabilities" ... so they would not have to see things they are not interested in). I've experimented and noted that if org.eclipse.sdk plugin is copied over to a callisto stack, then BIRT and WTP capabilities "magically" appear. (There is not even a 'capabilties' preference at all, if it is not there). My concern is that just a "bandaid" fix of providing a "callisto feature" doesn't really fix the issue I'm concerned about. The issue that I'm concerned about is the same that Jeff's voiced, I think, that if somemone installs this "magic" plugin (no matter what products they have, etc). then they will "suddenly" get some new capabilities (in prferences, anyway, the true capabilities always there). This will obviously take some deep thought, and a proposal should include tryng to solve both side of the problem: callisto type users not getting any capabilities, and users of "adoper products" "magically" getting too many, if they installed some extra plugin. (In reply to comment #24) > We in WTP put our capabilities in "product" plugins, and those are defined as > part of a "runtime features". They are not broken out in seperate "product > feature", but perhapss should be to allow adopter products to more easily omit > them, and ship their own? I'm actually facing this problem with WTP right now. IMHO it's a help for adopters if you define capabilities. This reduced the effort for adopters define them and allows a consistent naming through all Eclipse based products (users feel home ;). I wish JDT, Team/CVS and PDE would follow this approach. However, the problem is default enablement. I would like to ship my product with some capabilities turned off by default. However, WTP defines a default-enablement for them. > I've experimented and noted that if org.eclipse.sdk plugin is copied over to a > callisto stack, then BIRT and WTP capabilities "magically" appear. (There is > not even a 'capabilties' preference at all, if it is not there). This was interesting when I noticed it. I had to redefine the preference page in my product. I think the intention behind this is that you can create products where activity enablement cannot be controlled by a user. However, another side effect is that you suddenly have two preference pages if someone accidentally installs the SDK into your product. These are exactly the kinds of problems we are on about. Don't get me wrong, the situation is not particularly happy but the fact is, capabilities are in the eye of the beholder. What makes sense for one product may not make sense for another. Even enablement defaults are not obvious across products or scenarios. WTP having its capabilities embedded in its runtime features is in effect exposeing their view point to all takers. The Platform/PDE/JDT features are providing nothing to their users. The proposal is to have a specific feature on Callisto that people can get that would supply this productness to people's configurations. They don't have to depdent on this feature when they are creating their feature structures but they have the option of getting the capabilities if desired. It's not clear how reasonable the proposal is at this point in time but this does seem like a problem worth addressing. See also bug 130502 for similar issue (which could also be solved with the "hack" of having a "callisto product" feature and plugin). As for capabilities being "in the eye of the beholder" ... I think that presupposition is debatable. Perhaps I don't understand them very well, but seems like those plugin providing the function (and the trigger points) are precisely the ones to say what the capabilities are ... then, of course, products may want to enable/disable them based on the products target audience. (or, maybe even "group" them differently). .. the actual "core" definition would not seem that debatable. Perhaps you could educate me with some examples of how some are "in the eye of the beholder"? I might think that something is (not) worth defining a capability for. Your view might differ. In your view of a workflow, you think point X is a good trigger point. In my view point X just never occurs. In any event, defining them is like defining a bunch of classes. They don't do anything unless called. So you can define as many capabilities as you want but you cant do anything about how, where, or when they are exposed or enabled. These are things that are, in the general case, dictated by the context of the user as understood by the "product" or workflow. In the discussion here I was more focused on the second part of this (display, enablement, naming, ...) than on the identification or precise definition of a capability. As I understand it, you need both to get a coherent system. > In any event, defining them is like defining a bunch of classes. They don't > do anything unless called. So you can define as many capabilities as you > want but you cant do anything about how, where, or when they are exposed or > enabled. That makes defining capabilities sound somewhat harmless. But, once you put something (a wizard, preference page, etc) in a capability, that something is hidden from the user till the capability for it is turned on. That's why WTP has the default enablements. You don't want to install a product and then when you bring it up, have all the features hidden. And there's also the issue of if more than one capability includes the same wizard/preference page. As long as one is enabled, the wizard/preference page will show. That typically makes sense. But sometimes it makes it harder to hide features because you have to make sure all the capabilities that show it are disabled. (you may want to hide features if you are providing an even better feature) Bug 130967 might help in some way in the preciseness of capability definitions. (In reply to comment #29) > That makes defining capabilities sound somewhat harmless. But, once you put > something (a wizard, preference page, etc) in a capability, that something is > hidden from the user till the capability for it is turned on. That's why WTP > has the default enablements. You don't want to install a product and then when > you bring it up, have all the features hidden. And that's wrong. What I'm redistributing WTP as part of an corporate SDK for developing our product? In this case I explicitly do not want to expose certain WTP wizards and preference pages because they are useless when developing our product. They just cause confusion to new developers using Eclipse the first time. Enabling capabilities by default blows away the whole concept behind capabilities. In WTP you want to enable them by default in your SDK and for user explicitly downloading WTP for Eclipse 3.2/Callisto. I may haved missed something but I think there are two problems. 1) The definition of the extension point/preferences page for capabilities is in the SDK. This is the bug as it should be in the platform runtime somewhere. 2) The definition of the SDK capabilities is in the SDK. This really isn't a bug.The SDK is a product. The runtime platform should have the preferences pages defined in it. The SDK is a perfectly fine place for the SDK capabilities to be contributed to the defined platform capabilities preferences. In comment #31, point 1) seems like a bug to me as well. Given that this would be an API change though, it will have to wait for R3.3 Could a separate plugin be put in that would not interfere with the SDK if it were present? (In reply to comment #31) > I may haved missed something but I think there are two problems. > 1) The definition of the extension point/preferences page for capabilities is > in the SDK. This is the bug as it should be in the platform runtime somewhere. I agree that it would be interesting to have a mechanism in the runtime for enabling and disabling installed function. Note however that capabilities are not such a mechanism. Capabilities is a UI mechanism for filtering UI contributions (views, menus, ...) As such, capabilities as they are now should not be part of the runtime. We are very interested in looking at a general mechanism for managing function that would go at the runtime level. Some of the original discussion around capabilities involved such concepts but in the end we did not know enough about the usecases to justify the potential complexity. Anyway, that feels like a different scale of problem than what is being discussed here. > 2) The definition of the SDK capabilities is in the SDK. This really isn't a > bug.The SDK is a product. > > The runtime platform should have the preferences pages defined in it. The runtime has the notion of preferences but not the notion of pages. That is a UI thing. Regarding comment 34. Sorry I should have been more clear. By Platform runtime I meant the downloadable plaform runtime binary package for the IDE workbench. Not the platform runtime core. Packaging concept vs eclipse development project thoughts. Didn't mean to imply it should drop into the core runtime. Just into the IDE platform runtime binary. I want to revive this bug and make a push to get something done in Eclipse 3.3. I don't have an opinion about where capabilities should be defined or about what should be in "product" plugins. The thing I care about is that the plugin org.eclipse.sdk is available only via the feature org.eclipse.sdk, which also brings in all of the source code for Platform/JDT/PDE. (This is what David Williams first complained about.) This is a problem because: 1. We want to include the plugin org.eclipse.sdk in our products. 2. We want to select the things we get from Eclipse via features, not via individual plugins. 3. We don't want our products to install the entire SDK (at least not by default). One of the suggestioned workarounds is for the products that want to do this to add the plugin org.eclipse.sdk to their own feature. That's what we are doing now (because we don't have any choice), but we consider it an ugly workaround and not a good long term solution. In comment #23, Jeff McAffer said, concerning adding the plugin org.eclipse.sdk to a product-owned feature: > Re comment 20. I'm not sure where the versioning comes into play. > I was not proposing anything wrt precise versions. If a plugin is part of a feature, then the feature needs to specify the exact version of the contained plugin. So the feature owner would need to pay attention to the exact version of org.eclipse.sdk. That plugin would have to ship with the product. When installing the product into an existing Eclipse instance, it wouldn't be possible to reuse an existing org.eclipse.sdk plugin unless it had the exact same version number. We face this problem as well. We use capabilties in our products but currently the user can't enable/disable them. We don't want to add this plugin to our feature as that doesn't make a whole lot of sense. They could update the platform from the updater, but not our product. This just seems flawed. I don't understand why the capabilities bits are not a part of the platform runtime. Actually, it seems that the capabilities support is in the platform. Only the pref page to enable/disable capabilities is in the sdk plugin. Is that right? If so, that doesn't make much sense IMO. We don't like the preference page solution which is why it is in the IDE - enabling disabling/capabilites should be done either internally in your app or with a much richer interface (such as intro) that is easier for the user to use. If a product is designed to shell share (i.e. be in the same Eclipse instance) with other products (which may come from other companies), the product really doesn't have much choice except to use the org.eclipse.sdk plugin. If the product defined its own product plugin with its own menu definitions, that would clash with or duplicate the menus from the other products in the same shell. org.eclipse.sdk is the only common place where those things can be defined. We have considered not using org.eclipse.sdk and replacing it with our own plugin, but that really isn't workable due to the shell sharing problem. That's why we are begging that the org.eclipse.sdk plugin be packaged differently so that it is easier to use. I am not asking that org.eclipse.sdk be placed in the runtime features (because there are users and adopters who have a good reason to not want to use it), just that it not be in the same feature as all the source code (because some adopters want org.eclipse.sdk without the source code). It is unclear exactly what the right path for everyone is here. It is not a problem to have multiple products in the same Eclipse configuration (we in fact ship with 2) so I am not sure why the dependency on the org.eclipse.sdk plug-in is an issue. The only thing that binds the capabilities to the product is the triggerPointAdvisorProductBinding - if you are using your product you don't get these but you could use them if you wanted to for your own product. So is this just a packaging issue then - i.e. the problem is that the source feature is the only one that has the org.eclipse.sdk plug-in and you don't want source? I don't think we want this in a runtime feature. Can someone attach a plug-in or plug-ins of the suggested form they think we should ship? We (IBM Rational) would be happy with a simple packaging change. The simplest change that would satisfy us would be to create a new feature (I'll call it org.eclipse.sdk.only, though I hope someone can come up with a better name) which would include only the plugin org.eclipse.sdk, nothing else. The existing org.eclipse.sdk feature would be changed to include the new feature org.eclipse.sdk.only instead of the plugin org.eclipse.sdk. That simple change won't make everyone happy. I'm not objecting to more drastic changes (such as redefining how capabilities work), but I'm not advocating for them. I don't see us making a new feature. The general approach is that you simply include in your feature the plugins that you want. If you need the org.eclipse.sdk plugin to be there, include it in your feature. We will never be able to slice and dice the Eclipse project plugins in all possible feature sets that people want. (In reply to comment #42) > ... > We will never > be able to slice and dice the Eclipse project plugins in all possible feature > sets that people want. > I can't resist commenting that this does not seem like a "slice and dice" feature set problem to me. It seems fundamentally wrong that _any_ function (capabilities, in this instance) should be associated with "source or not source" or "sdk or not sdk". Well, there might be some features, if it really was, somehow, "developer only" functions, but never "end user" function .... but in the realm of IDE's that'd be rare. I think the general feeling here is that it's "strange" that capabilities are a part of the platform, but there's no UI for dealing with them in the platform. The reason Tod stated was because "We don't like the preference page solution which is why it is in the IDE - enabling disabling/capabilites should be done either internally in your app or with a much richer interface (such as intro) that is easier for the user to use." I think that's a fair statement, but still feels a litte "strange". The pref page class is in org.eclipse.ui.activities, but the extension for it is not. If you leave it up to IDE providers to sort of do it their own way, you'll at best get a lot of different solutions with little consistency, and at worst (and the most likely IMO), they will just add the extension to one of their own plugin xml's. Then when any of these features are installed together, or with the SDK, you'll get multiple capabilities pref panels. I don't know. Right now we don't have this panel in our products, but sometimes users tell us they need it to enable some things we "hide" by default. So I tell them they have to go download the sdk plugin, which comes with source and such. Way more than they need for the one pref panel. Maybe the easiest thing to do is move the extension to the workbench plugin, but "hide" it by default. Maybe IDE providers can specificy some flag in the config.ini file if they want it displayed? Not even sure if that's possible though. :) We discussed this afte the arch call today and we believe the easiest answer is for us to create an org.eclipse.sdk.capabilities plug-in and move the capabilities to it. If there are no objections I will make the request to the pmc. where is the plugin going to live? (what feature?) I assume not in the SDK feature. If so, why does it have SDK in the name? Perhaps IDE would be more appropriate? What product will these activities be associated with? Fundamentally, what is the difference between this new bundle and the existing org.eclipse.sdk bundle? Is there a flip side to this that now including these new capabilities in the base feature will disrupt people who have previously not had the capabilties defined there? where is the plugin going to live? (what feature?) We would have it live in whatever feature the SDK currently lives in. However the other Europa components may choose to package it thier features. >I assume not in the SDK feature. If so, why does it have SDK in the name? Perhaps IDE would be more appropriate? IDE might be a better choice. >What product will these activities be associated with? The SDK product for sure. One of the purposes of the split is to allow other products to re-use our activities without having to ship our product. >Fundamentally, what is the difference between this new bundle and the existing >org.eclipse.sdk bundle? This is the sdk bundle without the activities. Effectively we are spliting the sdk bundle into 2. > > Fundamentally, what is the difference between this new bundle and the existing
> > org.eclipse.sdk bundle?
> This is the sdk bundle without the activities. Effectively we are spliting the
> sdk bundle into 2.
Which argues that leaving sdk in the name is fine. Remember, this is just being done as a convenience for a particular set of consumers (e.g. Europa).
I don't think that creating another plugin for this makes much difference. Unless I am missing something, the org.eclipse.sdk *plugin* is small, simple, and has all that is required. It happens to offend some by having 's', 'd', 'k' contiguously placed in its name. While unfortunate, I think that the confusion caused by creating another bundle (with whatever name) would be further disruptive. Since we seem to have this discussion every year there is clearly something at play. I'll take a stab at consolidating the technical side of things in the hope that we can lay this to rest. There are four distinct parties at play in the area of capabilities. 1) functionality definer, 2) capabilities definer, 3) product definer and 4) someone who corelates capabilities (#2) with products (#3). So if we did each of these in a separate bundle, Bundle 1 defines some function and contributes some extensions. Bundle 2 groups various extensions into capabilities/category structures. Bundle 3 defines declares a product Bundle 4 defines *a* binding between the #2's capability definitions and #3's product. In the current case the org.eclipse.sdk bundle happens to have instances of 2, 3 and 4 in it. It is important to note that product definitions are only used if they are actually requested and that capabilities bindings (#4) and thus a particular set of capabilities (#3) are only used if the related product (named in #4) is active. In english, you only get the capabilities defined for the Foo product if you are are actually running Foo. Otherwise all that plugin.xml is just wasted diskspace. All of this means that ANY one is free to add the org.eclipse.sdk bundle to their feature, configuration, whatever and define their own product (#3) and capabilities binding (#4) to cause the org.eclipse.sdk capabilities definitions to be used. So, pragmatically, what does this mean for Europa? As I understand it, the EPP (Eclipse Packaging Project) is going to define a set of packagings that are easy to consume by the community. As such they seem particularly well placed to define the "product" (#3) and capabilities bindings (#4). They may even want to create basic capabilities definitions (#2). These definitions would be captured in a bundle (named as they choose) and added to a feature (named as they choose). End-users would then get the package most closely aligned to their needs and get the related capabilities. In short, the capabilities mechanism is already setup to handle the composition problem being discussed here. Refactoring the org.eclipse.sdk bundle to separate all the related parties does not change/affect/help that. We should use the facilities as they were designed to be used. I'm more confused than ever ... I opened this bug because if I install the "runtime" version of the Eclipse SDK Product, then I get no capabilities. Has this bug morphed into something else? you are confused because there is no such thing as "the runtime version of the Eclipse SDK product" as a download/update thing. If you go and get all the "runtime bits" (e.g., RCP, Platofrm, JDT and PDE), put them all together, add in the org.eclipse.sdk bundle, you will get what you want. That is what I am suggesting EPP do when they create their packagings. The Eclipse project team does not need to do anything to facilitate that. For all we know they are defining their own products and anything we did would be completely ignored. marking as WONTFIX as the packaging project should solve this problem in general (In reply to comment #51) > you are confused because there is no such thing as "the runtime version of the > Eclipse SDK product" as a download/update thing. If you go and get all the > "runtime bits" (e.g., RCP, Platofrm, JDT and PDE), put them all together, add > in the org.eclipse.sdk bundle, you will get what you want. That is what I am > suggesting EPP do when they create their packagings. The Eclipse project team > does not need to do anything to facilitate that. For all we know they are > defining their own products and anything we did would be completely ignored. > Ok, thanks Jeff. So, we in WTP can also pull it in and redistribute it, right? And ... Mylar, and DTP, and ... anyone else who might want to? BTW, I'm surprised users don't request a runtime version ... 70 megs vs 135megs! But, that's up to the community. Thanks again. Oh, I remember another reason now ... there is no Eclipse SDK version available on Europa, so ... there is no capabilities on Europa. (unless we all re-distribute, as you suggest ... which isn't all that bad of an idea ... just wanting to confirm that's the intent). (In reply to comment #54) > BTW, I'm surprised users don't request a runtime version ... 70 megs vs > 135megs! But, that's up to the community. That is what EPP is supposed to define. The consumable "runtime" pieces. The WTP distros that want the base capabilities should ensure that the org.eclipse.sdk bundle is present and that the right product/capability mapping is in place. From an update point of view this is ok as it just means the bundle is listed in more features (i.e., the bundle should NOT be downloaded/installed twice). In the zip file case the bundle is repeated but it is very small (56K compressed). since we are assuming that EPP will do something here, would it be reasonable to reassign this bug to them? Or perhaps we should open a new one and reference this one... Tod? David? someone want to carry that torch? Jeff I think we should open a new bug - there is too much traffic on this one FYI, I have opened bug 235039 in EPP project to discuss EPP solutions. |