Bugzilla – Full Text Bug Listing
| Summary: | Add GEF SDK to the EclipseRT category | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | Jeff McAffer <jeffmcaffer> | ||||
| Component: | RelEng | Assignee: | gef-inbox <gef-inbox> | ||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ahunter.eclipse, david_williams, hudsonr, irbull, nyssen | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Jeff McAffer
My vote would be for the gef.all-feature. This includes the GEF SDK, Draw2D SDK and Zest SDK. It also includes the examples, which really doesn't make sense in a "target". Is this ok Jeff? sounds at least in the ballpark. would be great to see the feature. I;ll dig it up or you can attach the xml here? Does it *include* things from other projects or just GEF stuff? It only "includes" stuff from GEF:
<includes
id="org.eclipse.draw2d.sdk"
version="0.0.0"/>
<includes
id="org.eclipse.gef.sdk"
version="0.0.0"/>
<includes
id="org.eclipse.zest.sdk"
version="0.0.0"/>
<includes
id="org.eclipse.gef.examples"
version="0.0.0"/>
<plugin
id="org.eclipse.gef.doc.isv"
download-size="0"
install-size="0"
version="0.0.0"
unpack="false"/>
<plugin
id="org.eclipse.draw2d.doc.isv"
download-size="0"
install-size="0"
version="0.0.0"
unpack="false"/>
But some of what it includes are other features. I took a look down the chain and it appears all the "includes" are just GEF things. There are some requires in the GEF feature for example:
<requires>
<import plugin="org.eclipse.core.runtime" version="3.2.0" match="compatible"/>
<import plugin="org.eclipse.ui.views" version="3.2.0" match="compatible"/>
<import plugin="org.eclipse.ui.workbench" version="3.2.0" match="compatible"/>
<import plugin="org.eclipse.jface" version="3.2.0" match="compatible"/>
</requires>
Look in tools under o.e.gef/features
(In reply to comment #1) > ... It also includes the examples, which really doesn't make > sense in a "target". ... I think it makes some sense. Its better than installing them in development environment! It allows a person to "run" them, see what they are, and then if they want to pursue further, they can import into their workspace (I assume they can import from the target, as before) and there study the code, tweak things, copy into their own apps, etc. I guess the downside is there's no easy way to get rid of them (as you can just close them in your workspace). So, I see "org.eclipse.gef.sdk" and "org.eclipse.zest.sdk" in current contribution. I take it you'll be adding a new one, that's some combination of these two? I also did not see these in any current category. That sort of makes sense to me, as I don't think casual end users will ever have to go and "install gef" to get some function ... the minimum runtime required will be "pulled in" by what ever other tools need it. But, having the SDKs there in EclipseRT category would be great. Please update your gef.build file and let me know the exact feature ID you want there. (In reply to comment #5) > So, I see > "org.eclipse.gef.sdk" and > "org.eclipse.zest.sdk" > in current contribution. > > I take it you'll be adding a new one, that's some combination of these two? Do we have to have 1, or can we have two features? (I don't know how many projects are contributing to the RT Category, but if there are a lot, then I guess the GEF project should only contribute 1). you can certainly have more than one but suggest you firmly put the consumer/developer hat on when designing the target offerings. You have to trade off apparent complexity at provisioning time (i.e., lots of different choices) with download size and complexity in configuring a running system (e..g., lots of extra bundles/feature to add to products/launch configs) On a different note, I assume that somewhere in the various GEF featurs mentioned there is some source? (In reply to comment #7) > On a different note, I assume that somewhere in the various GEF featurs > mentioned there is some source? > The SDK features should have the source. (In reply to comment #8) > The SDK features should have the source. The [gef|zest|draw2d] SDK feature includes the runtime, source and doc.isv. The [gef|zest] SDK feature also includes the draw2d SDK feature. So you really only need org.eclipse.gef.sdk and org.eclipse.zest.sdk features. Unless you do want the examples, in which case org.eclipse.gef.all (In reply to comment #4) > > I think it makes some sense. Its better than installing them in development > environment! It allows a person to "run" them, see what they are, and then if > they want to pursue further, they can import into their workspace (I assume > they can import from the target, as before) and there study the code, tweak > things, copy into their own apps, etc. David, the GEF examples (the one with the "SDK") don't work like you might expect. They cannot be run, and they must be used in a development environment because they are nothing but wizards which then create the source PDE source projects in your IDE, which you can then launch/run, assuming that GEF SDK has *also* been installed into your PDE target. Also, this example-project-creator bundle brings in additional dependencies on org.eclipse.ui and org.eclipse.core.resources that aren't needed for the GEF RT. thanks for the clarifciation Randy. Based on that, Anthony's propsoal "So you really only need org.eclipse.gef.sdk and org.eclipse.zest.sdk features." looks attractive. Agreed? (note that we can change this in the future) I think Anthony forgot to mention that the feature org.eclipse.gef.sdk contains the plugin org.eclipse.gef.examples.ui.pde. This plugin is the one I was referring to as the "example plugin" above. It's kind of confusing, since you can also get the more standard runnable versions of the examples. This plug-in is not part of the GEF runtime, nor is it source or anything else that would be useful in your target platform. It is an extension for your IDE. It has no dependencies on the GEF runtime, but it does add some dependencies that GEF RT doesn't have. Based on this bug's description, it didn't sound to me like the GEF SDK feature is what you'd want. hmm, are you suggesting that we need some new feature for this? alternatively, can the bundle you mention be moved out of the current feature? I am assuming Ian completed this for Galileo. From the original description, this bug was opened to: > Please indicate here the features to be included in this new category. My suggestion was in Comment #1. Beyond that, I'm not really sure what was required from the GEF team. Having said that, I'm not sure that this bug was ever "resolved": See Bug 280750. Bug 280750#c1, David suggests that GEF should not be in a category. In 280750#c5 Anthony suggests that GEF should be in the general purpose tools. Personally I think the GEF features should be categorized in Runtime, but maybe I'm the minority on that. In any event, I'm moving this back to the inbox, since there is nothing in this bug report than I can take credit for doing (other than voting). We can reopen if there is something for the GEF team to do. There is something for the GEF team to do. Identify a feature that is the GEF Runtime SDK (or some such). As described, this should include the GEF runtime stuff and source for the runtime stuff. It is what someone would add to their Target Platform if they were writing an RCP application that used GEF. Once this feature is selected then associate it with the EclipseRT Target Platform Component category in the Helios build contribution. I would suggest adding the following 2 features to the RT category: org.eclipse.gef.sdk org.eclipse.zest.sdk These features include only GEF related things, however, there are dependencies listed (actually, the dependencies are listed in sub features). Anthony / Jeff, where do you configure the Helios build contribution? (In reply to comment #19) > I would suggest adding the following 2 features to the RT category: > > org.eclipse.gef.sdk > org.eclipse.zest.sdk > > These features include only GEF related things See comment 12 and comment 18. org.eclipse.gef.examples.ui.pde does not belong in an RCP target. (In reply to comment #20) > See comment 12 and comment 18. org.eclipse.gef.examples.ui.pde does not belong > in an RCP target. Right. It's been a long day of triaging bugs. This is a little strange because we also have an examples feature that comes in as part of the "all" feature. But the example feature doesn't include this particular example. IMHO the GEF SDK should not include the example, but it's too late to change that without breaking clients. I can create a runtime-sdk feature for GEF that includes the GEF runtime, source + docs. If I can figure out build kick off mechanism, I'll take this for a spin. (In reply to comment #21) > I can create a runtime-sdk feature for GEF that includes the GEF runtime, > source + docs. If I can figure out build kick off mechanism, I'll take this > for a spin. This actually turns out to be a little harder than I thought. The GEF sdk feature is responsible for generating the source feature. If we create a runtime sdk feature, it will also need to generate the source feature, which will likely cause problems for our build (and consumers) -- the same feature generated twice. To provide the RT category with something consumable from GEF, we might want to consider the following 1. Create a GEF-RuntimeSDK (this includes GEF src, bin + docs) 2. Update the GEF-SDK to include the GEF Runtime SDK + the example This *should* leave us in the same state, that is, the contents of the GEF-SDK should remain the same, but it also gives us a more fine grained feature. Do we feel ok repackaging GEF this late in the game? Did I miss something with the repackaging that could cause consumer breakage? Created attachment 163349 [details]
Proposed structure
Here is what I was thinking.
The GEF SDK project will bring in the same plugins / features as it did before. However, it will now bring the GEF runtime ones in (gef and gef source) through the gef.runtime.sdk feature. (And the gef.runtime.sdk feature becomes the feature we use in the RT category).
Anthony or Randy, can one of you take a look at this. If things are ok, I will do the leg work to get this through our build system.
-1 for changing the SDK feature. The SDK has included the examples unzipper for five releases. All of the modeling SDK features also include the example zip, so if we are going to break GEF we are going to have to ask all the modeling projects to also change. Pretty sure the BIRT SDK also includes an example unzipper I suggest we bring in the GEF SDK as is and not start breaking the existing features and the build. BTW, where is the community feedback that we do not like the examples unzipper? (In reply to comment #24) > -1 for changing the SDK feature. The SDK has included the examples unzipper for > five releases. All of the modeling SDK features also include the example zip, > so if we are going to break GEF we are going to have to ask all the modeling > projects to also change. Pretty sure the BIRT SDK also includes an example > unzipper > > I suggest we bring in the GEF SDK as is and not start breaking the existing > features and the build. > > BTW, where is the community feedback that we do not like the examples unzipper? Anthony, My attached solution in no way removes the examples unzipper (at least that was not the intention). My attached solution simply introduces a new feature intended to be consumed by the target management tools. The existing GEF-SDK feature still ships source, binaries, docs and the examples unzipper -- just packaged slightly differently. I'm trying to be very careful not to break existing clients -- that's why I asked for the review. If I've accidentally removed the unzipper, then maybe there is something about the structure of GEF that I don't grok. (The SDK Feature still includes the o.e.gef.examples.ui.pde bundle, which I assumed was all that is needed to ship the unzipper). Anthony, can you take a shot at creating a GEF-SDK feature that includes the unzipper, and a GEF-Runtime feature that just includes docs, src + gef binaries. My intention is that we can keep backwards compatibility with all consumers of the existing GEF SDK feature and we can provide a runtime feature for the RT category to consume. I have to say that I've not followed all the ins and outs here but do have a couple high level thoughts. - we can do an incremental approach. The key thing is to get GEF in the Target Platform category for Helios. - in the long run the GEF SDK feature that goes in the TP category should likely not have any tooling stuff. If you have tooling in the TP stuff and the user adds GEF to the target with dependencies then all of a sudden their target is flooded with masses of tooling stuff they did not want. It is quite accpetable IMHO to have a GEF Tools (whatever) thing that gets installed into the IDE and a GEF Runtime SDK (whatever) that is for target platforms. Of course you can still keep the current features as super/sub sets. All we really care about here is what features are categorized and what that transitively includes. I'm not sure what the example zipper is. My guess is that you put it in the IDE to facilitate unzipping examples into the workspace. If so, it should be in a Tools category not the TP stuff. I'd be happy to participate in a call to sort this out... No, we have a GEF SDK and a GEF Runtime that has been shipping for ten years, I do not understand the need to start changing things for the runtime package. Can you tell me why the examples zipper is a problem? If it is for the runtime package, then it must be a problem for everyone. If we want development tooling, that is the SDK, if we do not, then that is the runtime. The documentation and source is required for development, so we do not need a new flavor of SDK, use the one we already have. Another angle, what runtime are we trying to look like? (In reply to comment #27) > No, we have a GEF SDK and a GEF Runtime that has been shipping for ten years, I > do not understand the need to start changing things for the runtime package. We have a runtime, but we don't have a runtimme SDK (runtime + source + docs), this is what I'm proposing. > Can you tell me why the examples zipper is a problem? If it is for the runtime > package, then it must be a problem for everyone. If the existing GEF SDK feature is added to the target, and I configure a product with this feature, my product will ship the example unzipper (and their dependencies). This is the situation we are trying to avoid. I think we are suffering from a terminology issue here. I would rather defer that discussion and focus on the features we need to have. In the TP category there should be a feature that is "GEF whatever" and transitively includes all of the runtime bits from GEF + the source. It can include programmer doc is you like as well. It should alos include any features that your community likes to use when configuring their products. It should NOT include tooling or other IDE functionality as it will not be installed into the IDE. What you do with any of the other features need not be affected in any way by this. So this is not a request to "change" anything. If you happen to have an existing feature that fits the bill, great. If not, then this is a request to create one. re the zipper, as I said, I don't really know what it is. If it is something that developers run while developing then it is a tool and goes in/with the IDE. If it is something that people generally add to their application/product and ship to customers then it likely is part of the Target stuff. (In reply to comment #29) > If the existing GEF SDK feature is added to the target, and I configure a > product with this feature, my product will ship the example unzipper (and their > dependencies). This is the situation we are trying to avoid. Exactly, this is what I need to understand. *My* IBM product also ships the GEF SDK which includes the example unzipper. You are saying the example unzipper is bad, why? (In reply to comment #31) > (In reply to comment #29) > > If the existing GEF SDK feature is added to the target, and I configure a > > product with this feature, my product will ship the example unzipper (and their > > dependencies). This is the situation we are trying to avoid. > > Exactly, this is what I need to understand. *My* IBM product also ships the GEF > SDK which includes the example unzipper. You are saying the example unzipper is > bad, why? OK, Sorry about this one. I fell off my chair and hit my head and now understand what you are asking. org.eclipse.gef.examples.ui.pde includes: org.eclipse.ui org.eclipse.core.resources org.eclipse.ui.ide Which are not included in GEF + Source + Documentation. By including the example unzipper, we are bringing in dependencies we do not want in an RCP application. (In reply to comment #32) > By including the example unzipper, we are bringing in dependencies we do not > want in an RCP application. Right, also at EclipseCon I saw a number of interesting GEF views (timelines for NASA planning for example). Would a user of this timeline application every want a button that loads the examples into their RCP application? If IBM has a need to ship the example unzipper, including the existing GEF SDK will accomplish this. The key to my proposed structure is not breaking existing clients (i.e. IBM), but rather enabling those clients who wish to *only* ship GEF and not the examples. (In reply to comment #32) > OK, Sorry about this one. I fell off my chair and hit my head and now > understand what you are asking. Thank goodness ;-) (In reply to comment #33) > If IBM has a need to ship the example unzipper, including the existing GEF SDK > will accomplish this. The key to my proposed structure is not breaking > existing clients (i.e. IBM), but rather enabling those clients who wish to > *only* ship GEF and not the examples. Sort of. In this bug we want to "enable those clients who wish to **develop against** GEF and not the examples." What they ship is up to them and you may or may not wish to include features that make it easy for them to put together a GEF configuration. The focus here is to get the right things in to the TARGET so that devs can PICK what they want in their PRODUCT. (damn caps lock...) Just for fun since we seem to have some closure on this (I hope), does the GEF tooling (the stuff that is not in Ian's proposed GEF Runtime SDK but is in the original GEF SDK) need GEF to be installed in the IDE? Gads that was a horrible sentence. Try this. Would it make sense to have a GEF Tooling feature that installed whatever you consider GEF tooling (e.g., the examples stuff)? Would/does such tooling require the GEF functionality to execute? (e.g., is there a GEF based view or something that opens in the tooling). If so, no problem. If not, perhaps you make a GEF Tooling feature that gets categorized somewhere in Helios (not the target category), the GEF Runtime SDK from Ian that goes in the Target Platform category and make the GEF SDK include those other two (that should then match the previous content) Jeff, org.eclipse.gef.examples.ui.pde bundle does not require GEF runtime to function. Having said that, the SDKs for the main eclipse project would benefit from a "tooling" feature too. *.src bundles belong in the target, so they qualify as "SDK". But *.doc.isv bundles belong in the IDE, with the help system. I think there are also extension points for debug's logical/detail formatters. I'm not sure if the JDT picks up these extensions from the target or only from the running IDE. (In reply to comment #35) > Jeff, org.eclipse.gef.examples.ui.pde bundle does not require GEF runtime to function. great > Having said that, the SDKs for the main eclipse project would benefit from a > "tooling" feature too. *.src bundles belong in the target, so they qualify as > "SDK". But *.doc.isv bundles belong in the IDE, with the help system. I think > there are also extension points for debug's logical/detail formatters. I'm not > sure if the JDT picks up these extensions from the target or only from the > running IDE. Right. I suspect that doc should go in the tooling feature not the target feature. Good point on the formatters. Likely that should be taken up with the PDE team as they have a model of the extension registry from the target and would be the ones contributing to JDT on the target bundle's behalf. Let me help to revive this discussion by adding my viewpoint as well. Maybe we can still make some progress towards 3.7 with this one... Let me summarize that from the discussion that happened so far (and I agree to this) org.eclipse.gef.sdk and org.eclipse.zest.sdk would be the perfect candidates for the desired runtime, except - and that is the only hindrance from my point of view - that org.eclipse.gef.sdk currently includes the already mentioned org.eclipse.gef.examples.ui.pde plug-in. Let me add that I do not only see a problem with the additional dependencies, but that I also see some sort of inconsistency w.r.t. to the org.eclipse.draw2d.sdk and the org.eclipse.zest.sdk features, which do not bundle examples. As such, instead of introducing yet another (org.eclipse.gef.runtime.sdk) feature, which would in my eyes only increase complexity and add some more confusion (because the inconsistency remains), what would really oppose to simply moving the org.eclipse.gef.examples.ui.pde plug-in from the org.eclipse.gef.sdk feature to the org.eclipse.gef.all feature? The only impact it would actually have is that existing clients, which 1) depend on the org.eclipse.gef.sdk feature AND 2) really depend on bundling the org.eclipse.gef.examples.ui.pde plug-in would have to change from org.eclipse.gef.sdk to org.eclipse.gef.all. If somebody depends on org.eclipse.gef.sdk and does not require the org.eclipse.gef.examples.ui.pde plug-in, there is nothing to change, because all plug-ins that he depends on are still there. And if somebody depends on org.eclipse.gef.all he would not notice any change at all. For those that would actually be affected because they depend on the org.eclipse.gef.sdk AND actually require the org.eclipse.gef.examples.ui.pde plug-in (I assume these people are rare), would it actually be a problem to change there dependencies from the org.eclipse.gef.sdk feature to the org.eclipse.gef.all feature? (In reply to comment #37) > Let me help to revive this discussion by adding my viewpoint as well. Maybe we > can still make some progress towards 3.7 with this one... > > Let me summarize that from the discussion that happened so far (and I agree to > this) org.eclipse.gef.sdk and org.eclipse.zest.sdk would be the perfect > candidates for the desired runtime, except - and that is the only hindrance > from my point of view - that org.eclipse.gef.sdk currently includes the already > mentioned org.eclipse.gef.examples.ui.pde plug-in. Let me add that I do not > only see a problem with the additional dependencies, but that I also see some > sort of inconsistency w.r.t. to the org.eclipse.draw2d.sdk and the > org.eclipse.zest.sdk features, which do not bundle examples. > > As such, instead of introducing yet another (org.eclipse.gef.runtime.sdk) > feature, which would in my eyes only increase complexity and add some more > confusion (because the inconsistency remains), what would really oppose to > simply moving the org.eclipse.gef.examples.ui.pde plug-in from the > org.eclipse.gef.sdk feature to the org.eclipse.gef.all feature? > > The only impact it would actually have is that existing clients, which 1) > depend on the org.eclipse.gef.sdk feature AND 2) really depend on bundling the > org.eclipse.gef.examples.ui.pde plug-in would have to change from > org.eclipse.gef.sdk to org.eclipse.gef.all. If somebody depends on > org.eclipse.gef.sdk and does not require the org.eclipse.gef.examples.ui.pde > plug-in, there is nothing to change, because all plug-ins that he depends on > are still there. And if somebody depends on org.eclipse.gef.all he would not > notice any change at all. > > For those that would actually be affected because they depend on the > org.eclipse.gef.sdk AND actually require the org.eclipse.gef.examples.ui.pde > plug-in (I assume these people are rare), would it actually be a problem to > change there dependencies from the org.eclipse.gef.sdk feature to the > org.eclipse.gef.all feature? Let me add that - as the discussion has already unveiled - the org.eclipse.draw2d.doc.isv and org.eclipse.gef.doc.isv plug-ins could also be candidates for not being included in a runtime feature (as such I was not correct with addressing org.eclipse.gef.examples.ui.pde to be the only hindrance for the sdk features to be 'perfect' runtime features). But as they do not bundle any source code I think they are rather uncritical. Having reconsidered this (again): what would actually speak against including the respective source-features directly within the org.eclipse.draw2d, org.eclipse.gef, and org.eclipse.zest features (similar to as it is done in the org.eclispe.gef.examples feature)? This way these features could serve as the (now indeed perfect) runtime-features (because they only contain the bare runtime plug-ins and their sources) while clients of the sdk features would not be affected by the change at all. (In reply to comment #39) > Having reconsidered this (again): what would actually speak against including > the respective source-features directly within the org.eclipse.draw2d, > org.eclipse.gef, and org.eclipse.zest features (similar to as it is done in the > org.eclispe.gef.examples feature)? This way these features could serve as the > (now indeed perfect) runtime-features (because they only contain the bare > runtime plug-ins and their sources) while clients of the sdk features would not > be affected by the change at all. If we do it this way (and forget what I have said in comments #37 and #38), I think that would be the better option. The non-sdk features could be regarded as the runtime features and the sdk-features could bundle everything that is needed in the tooling context. We could even think about moving the org.eclipse.gef.examples feature from the org.eclipse.gef.all feature down to the org.eclipse.gef.sdk feature, so that the org.eclipse.gef.all-feature would only have to bundle the two sdk features and the gef.sdk feature would actually contain everything related to gef. As there has been no reply to my latest comments I assume we may think of this to be either settled or not of interest any more. Resolving as WORKSFORME. We may reopen if this still requires some action. |