Community
Participate
Working Groups
Use this update site: http://download.eclipse.org/tools/emf/updates/ expand it, and select the EMF SDK R200406280827 category. Click next and there are no features found, even though features are available in that category. If all the categories are selected, the features are found.
Yes, the resolution is to select both EMF SDK and EMF SDK R200406280827, or EMF and EMF SDK R200406280827 (to install EMF). For SDO/XSD, you can either choose the SDK and a version of the SDK (as above) or a version + SDO / XSD. I realize this is clunky, and not at all intuitive, but it does work, sorta. ;-) I suspect this might be a problem with my site.xml - if that's the case, then it's a matter of having cross-categorized updates into two categories. (Or perhaps something else?) view-source:http://download.eclipse.org/tools/emf/updates/site.xml and you'll see (for example): <feature url="features/org.eclipse.emf_2.0.0.R200406280827.jar" patch="false" id="org.eclipse.emf" version="2.0.0.R200406280827"> <category name="Eclipse Modeling Framework"/> <category name="EMF SDK R200406280827"/> </feature> Is this wrong? Should jars be categorized by only ONE category? The code to generate this site.xml is a modified version of what I was given by Sonia Dimitrov, which was (at the time) being used to generate the site.xml and jars for the I builds of Eclipse 3.0.0 prior to its R release. My version is located here: Script: http://dev.eclipse.org/viewcvs/indextools.cgi/emf-home/emf-build/scripts/buildUpdate.sh Resulting site content (copied onto download in step 8 of the above script for mirroring purposes): http://dev.eclipse.org/viewcvs/indextools.cgi/emf-home/update-site/
I think cross categorizing a feature is desireable, so I'd leave this as a bug for update. The eclipse update site does not run into this problem because each category is a build (or a release), as opposed to a technology. Perhaps you could do the same: have all the emf related subprojects contained under the same category and the category being the build number. This is also useful when someone wants to go to a particular build, and then install one of the features it finds there. Sometimes there are feature dependencies, in which case the user will just select the pre-req'd feature from the same build.
So, you mean I should use the simpler <category name="M200407211027"/> instead of <category name="EMF SDK M200407211027"/> and <category-def label="EMF SDK M200407211027" name="M200407211027"> ... </category-def> instead of <category-def label="EMF SDK M200407211027" name="EMF SDK M200407211027"> ... </category-def> ?? That's a pretty easy fix, if that's all that's required here. Does the first letter prefix (I, M, R, S) make a difference? On http://download.eclipse.org/testUpdates/site.xml, you don't use build type prefixes, but we do - should I drop those out too?
No, the issue is cross categorization. You need to get rid of the "EMF SDK", "Eclipse Modeling Framework", etc. categories and only keep the build-based categories. As the build based categories all start with EMF SDK build_number, you can safely remove the EMF SDK prefix and leave the build numbers (keep the I,S, etc.) On the testUpdate site, only integration builds are published, for testing purposes, so it is probably not a good model to follow to the letter (no pun:-) Another optional setting: if you set the environment attributes (ws, nl, os, arch) to empty string or "*", the site lookup will be slightly faster, as the feature jars will not be read in to discover if they match the current environment. Set them on each <feature> element in site.xml. Even further, if your feature <include> other features,it also helps to set those attributes on the <include> element.
tentatively for 3.1
*** Bug 73686 has been marked as a duplicate of this bug. ***
install wizard has been redesigned (bug 85101) and this problem should no longer exist.
