Community
Participate
Working Groups
We have an application that uses the EMF runtime. It seems that the org.eclipse.emf feature in emf-sdo-runtime-2.x requires JDT. I think the features should be rearranged to minimize external dependencies. A simple rule to split would be: which other (external) plugins does a feature depend on. Clearly, the EMF runtime and Edit does not need any UI or JDT. Edit.ui needs eclipse UI and codegen needs JDT. Installing unneeded plugins is not a big problem. However, having a plugin that does not work, because it needs some other external plugins is a problem. Codegen does not work unless JDT is installed. That qualifies it (in my view) to be a separate feature.
Michael, Yes, this sounds like a very good idea.
I was testing eclipse 3.2(M3) and EMF 3.2(M3) and how it would work with our 3.1-based stuff when I fell over dependencies to "org.eclipse.jdt.core" and "org.eclipse.jdt.launching" in the following plugins: org.eclipse.emf.importer.java.jar org.eclipse.emf.codegen.ui.jar org.eclipse.emf.codegen.ecore.ui.jar org.eclipse.emf.codegen.ecore.jar org.eclipse.emf.codegen.jar org.eclipse.emf.codegen.jar I realize that most of them are codegen-plugins, so the JDT-dependency could really be moved out of EMF-Core into a new Feature "EMF Code Generation", this would help us with our Product immensely...
Created attachment 58476 [details] a view of EMF 2.3 as seen by Update Manager, unfiltered, + Mylar for comparison
Created attachment 58477 [details] a view of EMF 2.3 as seen by Update Manager, filtered, + Mylar for comparison
I've provided these screen shots to show what's possible, and what the limits are with Eclipse 3.3's current UM implementation. UM allows for two-tiered categorization (see Mylar's examples) and also allows features to include other features (EMF's SDK contains 9 features), which can be collapsed if users want their EMF experience to be smooth or chunky. Food for thought. ;-)
*** Bug 175032 has been marked as a duplicate of this bug. ***
Martin Oberhuber suggests that Windriver would like to see a subset or subsets the would include org.eclipse.emf.common org.eclipse.emf.ecore org.eclipse.emf.ecore.xmi, org.eclipse.emf.edit org.eclipse.emf.ecore.change org.eclipse.emf.edit.ui org.eclipse.emf.common.ui I could imagine org.eclipse.emf.common being a feature in and of itself (for the useful collection classes, the basic command framework, utilities, such as URI, and EMFPlugin). Then I could imagine a core runtime that consists of common, ecore, and ecore.xmi (and perhaps change, but that's more of an extended runtime). A basic edit feature would include emf.edit and the core runtime. A basic ui feature would include the rest plus edit.ui and common.ui (although common.ui depends only on common, so could be separate). As we move up the stack, this list of potential features will grow rapidly. We'll need to think about how many features are too many. Of course we can still provide overall features that group smaller feature into larger groups. But that makes the worst case of n features for n plugins turn into an even larger (exponential?) possible number of combinations, which is of couse silly.
We're proposing the following set of features. Indented below each feature name are the plugins in that feature. The "*" is for features that will require a new branding plugin. Comments are welcome. org.eclipse.emf.common org.eclipse.emf.common org.eclipse.emf.common.ui org.eclipse.emf.common.ui org.eclipse.emf.ecore org.eclipse.emf.ecore org.eclipse.emf.ecore.xmi org.eclipse.emf.ecore.change org.eclipse.emf.edit org.eclipse.emf.edit org.eclipse.emf.edit.ui org.eclipse.emf.edit.ui org.eclipse.emf.ecore.edit org.eclipse.emf.ecore.edit org.eclipse.emf.ecore.change.edit org.eclipse.emf.ecore.editor org.eclipse.emf.ecore.editor org.eclipse.emf.codegen org.eclipse.emf.codegen org.eclipse.emf.codegen.ui org.eclipse.emf.codegen.ui org.eclipse.emf.codegen.ecore org.eclipse.emf.codegen.ecore org.eclipse.emf.ant org.eclipse.emf.codegen.ecore.ui org.eclipse.emfcodegen.ecore.ui org.eclipse.emf.converter org.eclipse.emf.converter org.eclipse.emf.importer org.eclipse.emf.exporter org.eclipse.emf.importer.ecore org.eclipse.emf.importer.java org.eclipse.emf.importer.rose org.eclipse.emf.mapping org.eclipse.emf.mapping org.eclipse.emf.mapping.ecore * org.eclipse.emf.mapping.ecore2ecore org.eclipse.emf.mapping.ecore2xml org.eclipse.emf.mapping.ui org.eclipse.emf.mapping.ui org.eclipse.emf.mapping.ecore.editor * org.eclipse.emf.mapping.ecore2ecore.editor org.eclipse.emf.mapping.ecore2xml.ui org.eclipse.emf.ecore.sdo org.eclipse.emf.commonj.sdo org.eclipse.emf.ecore.sdo org.eclipse.emf.ecore.sdo.edit org.eclipse.emf.ecore.sdo.edit org.eclipse.emf.ecore.sdo.editor org.eclipse.emf.ecore.sdo.editor org.eclipse.xsd org.eclipse.xsd org.eclipse.xsd.edit org.eclipse.xsd.edit org.eclipse.xsd.editor org.eclipse.xsd.editor org.eclipse.xsd.ecore.converter * org.eclipse.xsd.ecore.importer org.eclipse.xsd.ecore.exporter org.eclipse.xsd.mapping * org.eclipse.emf.mapping.xsd2ecore org.eclipse.xsd.mapping.editor * org.eclipse.emf.mapping.xsd2ecore.editor org.eclipse.xsd.example org.eclipse.xsd.example
That's a lot of features. Are people actually asking for all those? Is this the smallest set achievable by grouping plug-ins by functionality (emf, sdo, xsd) and dependencies (no eclipse dependencies, rcp, platform, jdt, etc.)? Which of the features will have its own download zip?
Pratik, Yes, it's a lot of features. And yes, various people actually are asking for the pie to be sliced the way they want and there are many ways to slice it, so making small meaningful slices will let folks compose their own larger meaningful slice. This is a grouping of plugins based on functionality, so I'm not sure what you are asking; though it sounds like perhaps you are asking for yet another way to slice the pie. :-) Some folks don't want the UI, some folks think just the models are their runtime, others include the .edit support as runtime, because it runs stand alone too. Then there are folks building RCP applications. On and on it goes. So I want to be done with this once and for all and that's why I want to provide something that anyone would be hard pressed to argue will need further slicing. (And all this is why I strongly assert that features suck; my plugins and their dependencies should be sufficient without all these wrappers.) We are planning to provide just the downloads we already provide and then folks can pick them apart if that's what they want.
There are many optional additions to RCP, for example core.resources, ui.views, etc. But you don't see features anywhere that contain just these single optional plug-ins. At some point, the consumer simply has to capture the packaging choices they want.
The question is, at what point is that? At one extreme we have a single feature and at the other extreme, each plugin is a feature. Where is the right balancing point? Some folks don't even realize EMF supports RCP, so the one big feature is misleading. Other folks think EMF is too big, even though they depend on only a very small subset. In both cases, smaller features will help with the perception and improve the consumability of EMF. We're just trying to do the right thing for as many clients as possible but it's also clear you can't please all of the people all of the time...
The set of features proposed works for my particular scenario.
Will you provide corresponding source features?
We were going to provide only the same source feature we have now. I believe that such a source feature will work with any of the subsets, right?
Yes, though it would be nice to not have to make folks download all the extra source if it's not needed.
(In reply to comment #16) > Yes, though it would be nice to not have to make folks download all the extra > source if it's not needed. Agreed... but adding 26 new features is costly enough (time/maintenance) without doubling that to 52 (one feature + one source feature). Is this more than 'nice to have'?
I think that having some unused extra plugins in a feature does not hurt, as long as the extra plugins do not pull in extra dependencies (as was the case for the EMF feature pulling in JDT just because of codegen -- the original description of this bug). I'm wondering if the large number of proposed features could be reduced by putting more plugins - that have the same dependencies - into one feature. For instance, according to comment #7: "ecore.xmi (and perhaps change, but that's more of an extended runtime)" IMHO, being an "extended runtime" does not qualify it for living in a separate feature alone; as long as it just brings in functionality without new dependencies, it will never be activated and thus won't hurt. Similarly, just having UI plugins in a feature does not hurt as long as those UI plugins are not activated automatically or through extension points, or have dependencies to UI features or plugins listed in the feature.xml. A UI plugin that has no explicit dependencies or UI contributions does not hurt a plain non-UI-application, as long as the classes in the UI plugin are never referenced (and thus the plugin never activated). Given these throughts, can the list of features be reduced? Clearly, codegen and importer need to be separate. But does edit need to be separate from ecore? Does ecore need to be separate from common?
There's always a different excuse why people don't use EMF and one of the more common ones is that it's too big. So putting edit, which a very large portion of the clients don't use, in the core runtime does not help with that type of perception (even if it's not very big). So while it may well be true that having a few extra plugins that don't pull in new dependencies doesn't hurt (depending on your definition of pain), I would think that by the same reasoning it's also true that adding a few more granular dependencies doesn't hurt? Or do you see the former as painless while the later is painful? Having dependencies on plugins you don't actually need isn't totally without it's pain points. For example, if in a maintenance stream the emf.edit plugin is fixed but you don't depend on that plugin, you'll be picking up a maintenance fix anyway; picking up fixes is often a cause for concern to clients. And in general, having your deliverables bloated by unneeded, unused, and perhaps even inappropriate plugins (UI plugins in a non-UI application) is not entirely a good thing. Whether something needs to be separate seems to be in the eye of the beholder, so I'd rather produce a granularity that arguably is as fine as possible to serve the most diverse community possible and then never revisit this issue again.
These are all very good arguments. Thanks! I guess my only counter argument is that each feature by itself takes about 60KB of disk space as per EMF M6, so putting a plugin that's very small into a separate feature does add considerable overhead (and growing from 2 features to 26 adds 1.4MB of extra feature data -- the size of a full floppy disk in the good old days!) Also, when talking about not pulling unnecessary updates, keep in mind that updating a feature that's included in some other features REQUIRES updating all the container features as well, and does so automatically even if no plugins are changed in the process of this update. Otherwise, the configuration would be invalidated. This doesn't trump the argument of unnecessary updates but might weaken it a little if the concern is about download size: downloading 120K of never used plugins unnecessarily is not worse than downloading 120K of extra unneecessary feature data, IMHO. But perhaps the footprint of a feature can be reduced by getting rid of a feature image in case it's typically seen as included feature only.
Your points too are good ones. :-) I'll have to chat with Nick about your last point. I was expecting that we'd have only an overall feature that includes all the new small features, but that all these smaller features only have normal feature dependencies on each other. So I was expecting to have to update only the small feature and the main feature that I've always needed to update. This manual updating of version numbers is one of the things that ticked me off the most about doing this work. It's very tricky to increment all the right places during maintenance already and this will clearly make it much worse, so we will look into a mechanism to automate it (e.g., take a snapshot of all the MANIFEST versions and the feature versions at the start of each "cycle" and increment the feature's version automatically based on the largest type of increment of any contained MANIFEST). We could certainly consider rolling common.ui and emf.edit.ui together and perhaps rolling ecore.edit, change.edit, into emf.edit. I'd really like to keep emf.common separate though, because this provides the potential for folks to reuse things like URI, notification, EMFPlugin which works both standalone and in OSGi, in other plugins that have no Ecore dependencies and avoids the scenario where we might want to depend on them and they want to depend on us. I'd also really like to keep ui separate from non-ui since the ui things mostly make visible contributions that folks often don't need and don't want. As I've said many times, I think that features suck. We'd probably have been better off if we had only bundles. One could always define a "feature" bundle that's basically an empty bundle that just has dependencies on other bundles to pull them altogether into a single dependency. Then we wouldn't have this frustrating mishmash of two "bundling" concepts that seems mostly to create problems...
(In reply to comment #21) > I was expecting that we'd have only an overall feature that includes all the > new small features, but that all these smaller features only have normal > feature dependencies on each other. This sounds like a good strategy to me, and I think you're right that in case of an update only one child and the container need to be updated. Since I assume that the child features are for automatic consumption only while the larger one is for manual consumption, getting rid of the feature update icon in the children might be an option. > This manual updating of version numbers is one of the things that ticked me > off the most about doing this work. I think that the qualifier generation mechanism works well enough by now, so I'm not sure when you think you'd have to manually update version numbers? > We could certainly consider rolling common.ui and emf.edit.ui together and > perhaps rolling ecore.edit, change.edit, into emf.edit. I'd really like to > keep emf.common separate though Sounds good to me. > I'd also really like to keep ui separate from non-ui since the ui things > mostly make visible contributions Making visible contributions is a sufficient reason for me to have a separate feature for stuff that isn't needed. My comments were about UI widgets, for instance, that do not make contributions by themselves but can be used by extenders as kind of a toolkit. > As I've said many times, I think that features suck. Yeah... cheers to Jeff and let's hope the best for 3.4...
In a maintenance stream, when we fix a plugin that's version 2.2.2, we need to change it to 2.2.3, and we need to make a corresponding version change in the feature that includes that plugin. When we change another plugin before the stream is rolled into a release, we might have to change 2.2.1 to 2.2.2 for that plugin, but the feature's already been incremented, so we wouldn't need to do that again. These aren't handled by qualifier generation, are they?
Ah, I see... you are right. Still I think that with the setup you have in mind (1 master feature with many small child features) the extra effort should be manageable.
(In reply to comment #8) > org.eclipse.emf.ecore.sdo > org.eclipse.emf.commonj.sdo > org.eclipse.emf.ecore.sdo > > org.eclipse.xsd > org.eclipse.xsd There's a fly in the ointment here, since these features already exist as "runtime all-in-one features", and thus will have to change to accommodate this plan. There's also an org.eclipse.emf "runtime all-in-one feature", which will be removed to be consistent w/ the new organization of SDO and XSD's features. SDK features will continue to include all the same plugin content, but nested in the new subfeatures instead of using these 'all-in-one' features. I trust this won't be too onerous to work around for existing clients and developers. I know this is a late change, but once we're publishing builds w/ the new feature split, we'll provide whatever documentation we can to help people migrate.
Features have been created and appear to be packaged properly in the zips. However, tests are failing due to the fact that the single EMF source plugin is now 27 source plugins, and must be rewritten to accommodate this change. IBMers who want to get a jump on trying out this new EMF can get it from here: http://emf.torolab.ibm.com/modeling/emf/downloads/?showAll=1&hlbuild=0&sortBy=date&project=emf#latest Non-IBMers who want access to these Nightlies should ask me for them and I'll post them on our eclipse.org build server. If anyone wants access to an update site with these zips' jars, let me know and I can post something too.
(In reply to comment #26) > tests are failing due to the fact that the single EMF source plugin is > now 27 source plugins But there is only one SDK feature, right? - I think that splitting the features makes only sense for the runtimes. I do understand, though, that for every feature in the runtime you'll get a source plugin in the (or could the build.properties have a generate.feature@runtime-overall-container-feature line?)
> But there is only one SDK feature, right? Yes, still only one SDK which contains EMF, SDO, and XSD. There's still 3 SDK zips (EMF+SDO, XSD, EMF+SDO+XSD), and 2 runtime zips (EMF+SDO, XSD). I also managed to make the old emf runtime feature work, nested inside the SDK feature, so you can install that feature and still get the old behaviour for all emf features in one go. (I have yet to test this, however.) > for every > feature in the runtime you'll get a source plugin in the (or could the > build.properties have a generate.feature@runtime-overall-container-feature > line?) Putting all the source features back into a since feature is this morning's goal. This will fix two issues: a) feature-clutter (50+ features is a bit too much, IMHO) and b) broken tests which expect source in org.eclipse.emf.source/src/.
Update. Progress yesterday was good though Marcelo and I hit a few PDE-induced roadblocks [because features suck!] like the fact that you can't tell PDE to fetch sources for plugins and combine them into a single source feature UNLESS you have a single feature which contains all those plugins. So, to work around this limitation, Marcelo came up with the idea of having an SDK which is feature-based and an "All" which is plugin-based. We now have (F = feature, P = plugin): * F emf.all includes F emf.sdk + emf plugins; list is generated via script that checks CVS for folder names); this feature generates the source feature * F emf.sdk includes F emf (runtime) + F emf.doc + F emf.source * F emf (runtime) includes subfeatures + P emf (branding plugin) (this much is working -- see below for problems) * F sdo.all includes F sdo.sdk + sdo plugins; list is generated via script that checks CVS for folder names); this feature generates the source feature * F sdo.sdk includes 3 sdo features + F sdo.doc and F sdo.source !! build fails * F sdo used to include all 3 features' plugins; now is just a subset !! there is no "sdo runtime" feature at this point, but we might need one as we have for emf * F xsd.all includes F xsd.sdk + xsd plugins; list is generated via script that checks CVS for folder names); this feature generates the source feature * F xsd.sdk includes 7 xsd features + F xsd.doc and F xsd.source !! build fails complaining about not finding xsd.source * F xsd used to include all 7 features' plugins; now is just a subset !! there is no "xsd runtime" feature at this point, but we might need one as we have for emf Additionally, javadoc is broken in all three component builds. No ETA yet.
Update. SDK and runtimes look good -- everything is as before, except that there's an xsd.example in the xsd.sdk, which will be gone in the next N build respin. Javadoc is working. .doc and .source plugins looks good. Standalone and Models are still broken, which is preventing tests from being able to run. This is the last remaining hurdle to overcome, hopefully tonight.
Polish mode. 4 items to verify: * remove xsd.cheatsheets from xsd.runtime zip * prevent duplicate rootfiles when combining SDKs * tweak feature descriptions to avoid HTML entities ("don't" -> "don't") * add missing .project files to new features/plugins 2 items to complete/verify: * add modeling32.png icons to all subfeatures/plugins to make them appear under the Modeling icon in the Help > About dialog (?) * set up dependencies between subfeatures & plugins so that UM installs cannot be broken; use PDE to compute dependencies (plugins); must verify that UM's Select Required works with these changes; otherwise will have to use features instead
(In reply to comment #31) > * add modeling32.png icons to all subfeatures/plugins to make them appear > under the Modeling icon in the Help > About dialog (?) AFAIK, these images need to be in the branding plugins and NOT in the features. The "Feature Update Image" is only shown when you choose Properties after selecting a feature in the Update Manager. In order to reduce download overhead for the features, I'd advocate not setting the "feature update image" at all. > must verify that UM's Select Required works with these changes; otherwise > will have to use features instead I'm not sure if the UM ever considers plugin dependencies. Maybe it always looks at features only. At any rate, feature dependencies are safer than plugin dependencies if you want UM "Select Required" to work. Mylar converted everything to feature dependencies -- see bug #132450 comment 41.
(In reply to comment #32) > In order to reduce download > overhead for the features, I'd advocate not setting the "feature update image" at all. That's where I was a couple hours ago, and so for M7 I agree. I don't know if we'll decide to change this for RC1. We can discuss in detail later. :-) > I'm not sure if the UM ever considers plugin dependencies. Maybe it always > looks at features only. This was true for Callisto, but testing today seems to show otherwise. UM as of 3.3M7 DOES HANDLE 'SELECT REQUIRED', GETS THE MINIMUM REQUIRED (NOT SDKs), AND INSTALLS ONLY REQUIRED FEATURES AND THEIR CONTAINED PLUGINS. (Sorry for the CAPSLOCK, but this is so freakin' cool after complaining about this bug for two years!) Alert the media! ;-) Steps to reproduce: 1. unpack Eclipse 3.3M7 linux gtk version into clean folder 2. open eclipse, add http://emf.torolab.ibm.com/modeling/emf/updates/site-interim.xml update site, which has this morning's I build in it now (sorry, internal only for now). 3. do not 'choose mirrors automatically' 4. ignore mirrors, choose the last one on the list (the actual site) 5. expand twisty next to EMF SDK 2.3.0 I200705110650 (EMF + SDO + XSD) 6. pick something way down the food chain, like xsd.editor 7. note error 8. click 'Select Required' 9. note all the new features selected common.ui, common, ecore, edit.ui, edit, xsd.edit, xsd.editor, xsd 10. hit Next, accept licenses, hit Next, install to some location, hit Finish. 11. restart Eclipse. Check features and plugins are installed correctly. Note that because UM works with features, *plugins* ecore.change and ecore.xmi are now installed as they're part of the ecore *feature*. This sounds like perfect behaviour to me. 12. Do something to verify xsd.editor works, like opening an .xsd file in EMF's sample editor. Could also grab our EclipseCON 2007 workshop and try that out (http://download.eclipse.org/modeling/emf/updates/site-eclipsecon.xml). 13. Install just the Tutorial Exercises (not all the OCL stuff) 14. Launch Wizard for EclipseCon 2007 EMF Tutorial > Exercise Materials 15. In the created project, browse to EMF_Tutorial\Exercise01\BasicPurchaseOrder.xsd, and open with Sample XML Schema Editor (contributed by xsd.editor).
That's freakin' cool indeed ;-) When UM supports plugin dependencies for "Select Required", that may help a lot. Adding Mik Kersten to CC since he's the expert on bug #132450 (I believe).
Fix in CVS.
Fixed in 2.3.0M7 (S200705110650).
I'm surprised that the source plugins all contain .classpath .project build.properties I'm not aware that the Platform also adds these to their source plugins, is this intentional?
(In reply to comment #37) > Source plugins all contain > .classpath > .project > build.properties > Is this intentional? Not specifically, but they're not new. I don't know when they started appearing, but they were there in at least 2.3.0M6. Is this a problem?
As a followup to the feature changes discussed here, I've created the following document to ease migration. http://wiki.eclipse.org/index.php/EMF_2.3_New_Features_Migration_Guide If you have any concerns w/ the new organization or if the three suggested approaches will not work for your scenario, please post your comments here.
Reopening. Testing revealed some problems in the three new XSD branding plugins' about.properties files (see comment 8). Descriptive text points to EMF, not XSD.
Fix for three properties files in CVS; will be picked up in next week's build.
(In reply to comment #38) > > Source plugins all contain > > .classpath > > .project > > build.properties > > Is this intentional? > Not specifically, but they're not new. I don't know when they started > appearing, but they were there in at least 2.3.0M6. Is this a problem? Nick, development-time metadata/artefacts should not ship in a product. So at minimum, these files should not be part of the final product for good hygiene. These files may also cause problems when importing plug-ins into the workspace via the plug-in import wizard. Please plan on removing them.
(In reply to comment #42) > Nick, development-time metadata/artefacts should not ship in a product. > So at minimum, these files should not be part of the final product for good > hygiene. > Please plan on removing them. Did some more checking - they've been there since at least M5. I'll certainly remove them, but here's the catch: I can't figure out why they're there -- they're not mentioned in the build.properties in either the sourceTemplateFeature or sourceTemplatePlugin folders of the SDK features: these are generated features, as per this line in EMF's SDK feature's build.properties: generate.feature@org.eclipse.emf.source=org.eclipse.emf.sdk So... where are they being added? And how can I suppress them? This isn't the fault of our new feature reorg because they've been there since M5, so could it be a new default behaviour in PDE when generating source features? Can I fix this by adding 'src.includes=' directives in each feature's build.properties?
I'd propose opening a new bug for the source features including build.properties so we can focus on the feature setup here. With respect to the feature setup, the original problem is still there on the Europa site: * Start with Platform * Select Remote... > TM Service Discovery * Select Required --> picks TM Core, EMF Runtime AND JDT!! The JDT Dependency is what we do not want in this scenario. The reason for UM still picking JDT is that on the Europa site.xml, only the EMF-Runtime (overall) feature is listed but none of the included features. So even if TM only requires the smaller included plugins or features, UM has to pick the overall runtime feature which brings in the unwanted JDT dependency. As the fix is right now, only products which declare the features themselves and explicitly do not contain the EMF Overall Runtime can make use of this. And even then, "Search for updates of currently installed features" will only work if the site.xml of the EMF Update Site has all the smaller features as well as the overall runtime listed. For Europa, I see two possible fixes: a) List all the small EMF component features in Europa site.xml. For UM, make sure that "Show features included in other features in the list" is switched off by default. b) Create yet another EMF Overall Runtime Feature variant which includes all those EMF Component Features that do NOT require anything above the Platform. I think that for Europa, the important point is just whether it requires Platform or more so I'm slightly in favor of option (b).
I'm dead set against creating any more features. Surely there are enough features by now that creating yet more combinations of features themselves should be unnecessary. I don't understand this particular comment: As the fix is right now, only products which declare the features themselves and explicitly do not contain the EMF Overall Runtime can make use of this. I would certainly expect that products declare the features they want and not the features they don't want. Am I misunderstanding something? Is this a comment about declaring dependencies on plugins rather than on features? I don't see how the smaller features are actually useful if they aren't on any update site so option A for both the Europa and EMF update sites sounds like the right thing to do to me.
(In reply to comment #45) It's clear that all small features need to be in the EMF site.xml. Since products being installed without Europa will always reference the EMF site, they will be fine -- that's what my first comment was about. For the Europa site.xml, typical usage is to contain only a coarser granularity of features. I'm a little afraid that adding all those small features to Europa might confuse users (if the "Do not show features included in other features on the list" option is not switched on) - and I'm not 100% sure whether "select required" would work properly if it is switched on. If others are not afraid of this, then yes, option A is the right thing. Perhaps the right thing to do is go with (a) now and test how it feels in RC1. If we find that it does not look or work smoothly enough (dont know who would decide that), then B is necessary - defining yet another feature, with the right granularity, especially for Europa.
The problem I see with option B is what is the right level of granularity? How many right levels are there? And how many groups will have a different idea of the right level and will find it necessary for yet another feature that reflects their view of that right level? Sorry for my ignorance, but I wonder how is the platform handling this? I.e., how does one install just the platform without JDT. Is there no "overall" platform feature that includes all the smaller features of the platform? If there is, why isn't that already causing a similar problem?
(In reply to comment #47) > The problem I see with option B is what is the right level of granularity? Well, my proposal is specifically for Europa since we are talking about the Europa update site here. The right level of granularity is exactly what is in the current EMF-Runtime feature, minus those features that require stuff which is not in the Platform Runtime Binary (i.e. JDT). In other words, I'm proposing an "EMF-Runtime-Minimal" which is able to live above Eclipse Platform Runtime without JDT. > I.e., how does one install just the platform without JDT. Go to http://download.eclipse.org/eclipse/downloads, pick a milestone and then install the "Platform Runtime Binary". > Is there no "overall" platform feature that includes all the smaller > features of the platform? There are "overall" features for * RCP (smallest, 12MB), * Platform-Runtime (medium: 39MB, including RCP+IDE+Resources), * SDK (large, 139MB, including Platform+JDT+PDE+ISV Docs+Source). As you see, for people who do not want to do any Java, the SDK is an overkill. Also, the Europa Site explictly says "Minimum Requriement is the Platform", so why not better start with 39MB and get what I need rather than start with 139MB. People doing C/C++ development do not want or need JDT. > If there is, why isn't that already causing a similar problem? Platform as a framework has fewer disjoint feature sets than EMF. And those feature sets that it has, are orthogonal in the sense that all "add-on" features referenced are really needed -- for instance, PDE really requires JDT, CVS really requires Platform. But if I want to do Modeling, I cannot see why I need JDT. And I'm really grateful to you folks that you have solved this issue for the case where I'm preparing a product; I'm just mentioning that it has not yet been solved for the Europa site. But again, why don't we just go and try option (a) with all the small features on Europa, and revert to option (b) if it does not work?
Yes, I think we should try option A. That sounds most similar to what the platform is already doing...
Created attachment 68051 [details] two screen shots showing 'Search for new features' from Europa Discovery Site with Eclipse SDK 3.3RC1 installed (In reply to comment #49) > Yes, I think we should try option A. That sounds most similar to what the > platform is already doing... If by Option A you guys mean "add a boatload of tiny features to Europa" I'm not sure I agree. In M6, Europa was 90 features. It's dropped to 86 features as of M7, but you'll notice they're pretty coarsely grained (see screenshots). EMF/SDO/XSD used to contribute 4 features (one SDK + 3 runtimes) and now has 6 (a runtime and an SDK for each project). To add all the other features would mean we'd be adding about 23 new tiny features. That's not coarse-grained, that's over 25% of the entire Europa offering! Instead of adding new tiny features, we ought to be adding (if any) a larger feature, like Christian did w/ Query, Transaction and Validation. Instead of 6 features (one SDK, one runtime each), he's created a merged feature pair called "Data Integrity Frameworks" so there's even less to install and less confusing choices. It would not be a lot of work (I think) to split the monolithic emf "all features runtime" feature into chunks; however, this goes back to the debate about *HOW* to chunk it so that everyone's happy. If the goal for the sake of Update Manager is to have chunks w/ similar dependencies (JDT, for example), could we not have just two or three chunks? RCP, JDT, Others? (BTW, the 'Filter features included in other features on the list' works great w/ EMF/SDO/XSD: you either see 6 features (SDKs + runtimes) or just the 3 SDKs.) Or, maybe it's broken... see bug 188209 and bug 188210)
> why not better start with 39MB and get what I need rather than start with > 139MB. People doing C/C++ development do not want or need JDT. Do people doing C/C++ development want EMF? > But if I want to do Modeling, I cannot see why I need JDT. So, would better descriptive text in the feature to explain this prereq help? JDT is required for some parts of EMF, and if you're installing either the runtime or SDK features as they exist today (M7) in Europa, you will need JDT. (As a side note, see bug 187396.) UM finds all stated dependencies using 'Select Required', including the case where I want to install PDE and must install JDT as it's prereq'd. But I digress. I see at least three scenarios for Europa users - please correct me if these are crazy-talk. ;-) a) I want to develop standalone or RCP java apps w/ EMF. I prereq JDT. b) I want to develop plugins using EMF. Therefore, I prereq both JDT and PDE. c) I want to use something which prereqs EMF (eg., GMF) to develop something written in Java. Therefore, I prereq JDT, EMF, GEF... all of which are logical, since we're working graphically in Java. What scenario(s) exist where you're a Europa user, want to use EMF, but don't want JDT / can't handle the extra download?
I must say that I'm getting more and more annoyed about doing anything to make anyone happy since there isn't really anything that makes everyone happy anyway, so I might as well let the unhappy people remain unhappy it would seem. (Perhaps it's just the late hour and maybe I'll be less annoyed tomorrow.) The features are either too course grained or too fine grained. Some say there should be a feature that doesn't include JDT. Others want a feature that doesn't contribute to the UI. Sometimes the footprint matters, then other times it doesn't matter. When we provide all this, then there are too many features, and when we don't there are not enough features. The features should be completely separate or they should be included in other features, but when included in other features, that's a problem too. This just never seems to end and then the only solution is to create yet more features?! That's just too ironic for me to see a pattern that will just never end. When a plugin is updated in a maintenance stream I'm sure to have a lot of fun spending a few hours figuring out which features all needed to be incremented (verses those that have already been incremented because of fixes in other plugins) to keep this all working properly. One thing that really confuses me Nick is how exactly is a feature useful if it's not listed on *any* update site? And I'm also confused when I ask how the platform does this that pointing at the download site is part of the answer. My intent is to ask, does the platform provide a platform feature, a JDT feature, and a feature that includes both (along with things like PDE and CVS)? Whatever the platform is doing, it's reasonable that we should do the same and if we have 25 things instead of 5 things, so be it. And Martin, of the features we've already provided, which do you actually need in Europa and why do you need them in Europa as opposed to needing them only on the EMF site? (Sorry for the rant, but I've really completely lost patience with this.)
Ok, let me try and (hopefully) reduce some confusion: * Splitting EMF into smaller features was great, and helps already for products that come as pre-configured packages where the initial set of EMF features is selected by a person. Such products can even be updated automatically through UM, provided that the update site.xml which is listed in the features has all the small features embedded. * My recent comments were mostly about getting the initial feature set from the Europa update site. For instance, our "TM Service Discovery" component for remote service discovery uses only parts of EMF that would normally not require JDT. But, since the Europa site.xml only lists the larger overall features, we currently cannot get around installing JDT as a by-product. This is not a very big deal for us, since getting the commercial products right is much more important than those users who get the free stuff from Europa (and start with the Platform and do not want JDT). So if you're really fed up with it, so be it and leave it as it is. But if you're interested in improving the situation, there's options (a) and (b) mentioned.
PS Although it's not a big issue for us, here is what I personally think would be most aligned with the concept of the Europa site: * Reduce the EMF SDK Features to only 1 overall SDK (just like the downloads: programmers care much less about unnecessary dependencies than runtime users, and I find 3 different SDKs only confusing). It could be named EMF + SDO + XSD Extender SDK * 4 Separate Runtimes: Eclipse Modeling Framework (EMF) Core Runtime Eclipse Modeling Framework (EMF) Runtime + End-User Tools EMF Service Data Objects (SDO) Runtime XML Schema Infoset Model (XSD) Runtime So I propose adding one "Core Runtime" feature that includes everything from the existing EMF Runtime+End-User Tools but without the parts requiring JDT. * No separate runtimes for UI/Non-UI splitting because users of Europa always get the Platform UI, they cannot work around it. Users of headless need to create products their own. This would reduce the EMF Features on Europa from 6 to 5. And yes when you create a point patch or a service release there is one more feature to be updated with respect to version numbers, but it is a subset of a feature you have to update anyways so it would hopefully not be too hard. Again, it's just what I think, don't feel obliged if you think it's too much work or conflicts with other requirements...
BTW, I verified that when I use the native TM and EMF update sites instead of the Europa site, it works fine for me and I automatically get an EMF feature mix that does not require JDT. Unfortunately, Update Manager does not run completely smoothly yet when dependencies span multiple update sites, see bug #188318. Another reason why it would be cool to get that working for Europa too.
> * Reduce the EMF SDK Features to only 1 overall SDK (just like the downloads: > programmers care much less about unnecessary dependencies than runtime users, and I find 3 different SDKs only confusing). It could be named > EMF + SDO + XSD Extender SDK It could be, and it used to be, but because XSD is no longer a Modeling/EMF component (it's moving to Modeling/MDT) and SDO will eventually be obsoleted by Apache Tuscany, we're actually better off with them split. Besides, you wanted minimal EMF installs, and having to bring in SDO and XSD if you never user them sounds like the opposite to smaller features w/ less dependencies. As a user, if you know what SDO is, you can choose to install the runtime/SDK. If you think you'll need Schema support, you can install the aptly-named "XSD SDK" or its runtime. Is that really so confusing? > BTW, I verified that when I use the native TM and EMF update sites instead of > the Europa site, it works fine for me and I automatically get an EMF feature > mix that does not require JDT. Two easy options here that would negate the need for more features and changing anything in Europa: a) add the EMF Update site as one of your features' discovery URLs, so that while 'search for updates...' wouldn't find this new site, 'search for new features...' would be able to pick up that new site and you could get users to install JUST the non-JDT features they need. You can call that Discovery site anything you want, too -- if need not be "EMF Updates". You could call it "Modeling Frameworks" or "Enabling Features For Modeling." ;-) b) Use a policy file to override where users get their updates. You can point them to a different update site, several different update sites, or your own custom mirror where you've repackaged features to suit your needs. See bug 132450 comment 93.
Big features with unnecessary dependencies are not an issue for SDKs, but they are an issue for Runtimes. Thanks for the suggestion with the discovery site, but my concern is mostly about getting an initial install from the Europa site. I cannot see how the suggestions would help here? You seem to presume that something has been installed already. I think I'm getting tired of this as well :-( so why not just let it be...
(In reply to comment #57) > Big features with unnecessary dependencies are not an issue for SDKs, but they > are an issue for Runtimes. I guess I'm stuck on what the usecase is... are your users plugin developers? java developers? If either, then they already need PDE and/or JDT, so I'm at a loss what the problem is. If neither... then I suppose that yes, there's an issue. What are they using EMF for, if not Java? > Thanks for the suggestion with the discovery site, but my concern is mostly > about getting an initial install from the Europa site. I cannot see how the > suggestions would help here? You seem to presume that something has been > installed already. Yes, I'm assuming that as a Europa user, you've got either the Platform Runtime Binary or the SDK. As a developer, I'm assuming you might as well grab the SDK because while there's stuff in there you might not need, there's stuff that I consider pretty crucial for java development (CVS, JDT, ...). But again, I don't know your users/usecases. I understand the desire to make it easier for your users to get just the emf runtime bits they need from Europa. I'm just not clear: a) why having JDT as well is so bad? [too big a footprint?] b) why they can't get the bits from another site instead? [if they start with Europa's Platform Runtime Binary they need only add another Update site or use a policy file in order to get the smaller EMF features] c) whether the cross-project Europa community would appreciate us adding 23 more features to the mix > I think I'm getting tired of this as well :-( so why not just let it be... Forgive me for exhausting you on this... I'm just trying to weigh the impact of more changes and more maintenance vs. the current state of things and the current workarounds. ;-) Here's a scenario that might work... 1. User downloads Europa Platform Runtime Binary, with the intent to use it for your features. 2. Because they read some doc on your website/wiki about how to get a smaller install footprint, they know they can optionally add the EMF update site and update from that as well as from the Europa one. 3. They launch 'search for new features...' and install your stuff, optionally grabbing the smaller features off the EMF site instead of the Europa one, with your stuff and all other prereqs coming from the Europa site. 4. They restart Eclipse when prompted and boom, they're done. In scenario 2, they start with the SDK instead of the platform runtime, and can again either use the EMF site or the Europa site depending on their desire for a smaller download/footprint. Am I completely missing something, or does this resolve the twin goals of 'keep Europa simple' and 'allow users a smaller download / use smaller emf features', with only minimal documentation (eg., a single line of text + a link) on your website/wiki?
Fixed in 2.3.0RC1 (S200705230200).
(In reply to comment #43) > > Nick, development-time metadata/artefacts should not ship in a product. > > So at minimum, these files should not be part of the final product for good > > hygiene. > > Please plan on removing them. Wassim: Further investigation shows that development-time metafiles were added into our sources because of bug 170001, so assuming there was a good reason for that (which isn't documented in the bug), I guess this is a non-issue. If you violently disagree, please reopen that bug and file your objections there.
It looks like the discussion regarding dependency on JDT on the Europa site is carried forward on bug #189295 now...
Move to verified as per bug 206558.
