Community
Participate
Working Groups
Eclipse 3.2 M5: The Mylar Project (http://www.eclipse.org/mylar/) organize its plugins in many features. There is one "main" feature (org.eclipse.mylar_feature), and the others depend on this one: http://download.eclipse.org/technology/mylar/update-site/e3.2/site.xml I have the 0.4.9 version installed, and tried to upgrade to 0.4.10 using the "Search for updates of the currently installed features", but it only showed the "main" feature. It was necessary to update it, restart Eclipse and run update again to the other features be available for update. But, if instead of this, I have selected "Search for new features to install", selected the "Mylar Update Site", all features appear correctly. I checked the update site and each feature manifest, and it seems to be OK, so it appears not to be a Mylar bug, but a platform update bug. I think the "search on installed features" actually requires the dependencies to be updated before the dependent features. Is it correct? If so, then I think the update searcher should compute the dependencies, and being available, update all features only once, not requiring this "2 phase update". It is not practical nor intuitive.
Created attachment 36556 [details] Screenshot take when "Search for new features" was selected Note that all features appear to be updated
Created attachment 36557 [details] Screenshot when "Search on installed features" was selected first time Note that only the main feature was computed to be updatable.
Created attachment 36558 [details] Screenshot when "Search on installed features" was selected after restart On this time, the other features finally appear
Is this going to be addressed? For Mylar, which has 4 features, we currently have no choice but to state on the download page that users have to use "Search for new features.." because using "Search for updates" will only install one of the features as specified. This in spite of the fact that the features are specified as having a dependency. I.e. "Search for new feautures.." does not allow the install of a single feature without it's dependent features, but the update happily installs it and as such breaks the configuration.
I see this bug being a source of confusion and problems in the future, if it will be decided that we'll be able to upgrade the next maintanence releases of Callisto projects via update manager. For example: TPTP depends on BIRT, WTP depends on JEM, EMF and GEF, GMF depends on EMF and GEF.
Is anybody on Platform/Update looking at this bug report??? We have been working around most of the Update Manager's shortcomings but have no work-around for this one. As Willian indicates it will be problematic across the board for this to be in 3.2. Willian: I'm voting for this and ask that you do the same.
IMO, browsing Callisto update site with current Update Manager is a joke. It block the UI for about 10 seconds on expanding groups. When running "add required features" action it blocks for about 30..40 seconds if not longer.
+1, because I ran out of votes. BTW, please vote on bug#144338 too ;-)
(In reply to comment #7) > IMO, browsing Callisto update site with current Update Manager is a joke. It > block the UI for about 10 seconds on expanding groups. When running "add > required features" action it blocks for about 30..40 seconds if not longer. > Eugene, look at bug#138150 also.
(In reply to comment #9) > Eugene, look at bug#138150 also. It is no use. Apparently it is by design. The only way to resolve update manager issues is to put owners of this component on dial up connection and hope that it will motivate some innovation...
Re-marking this as critical in hope that it stops getting ignored. This bug still causes an illegal update since feature dependencies are not respected, and means that users can not always rely on the "Search for updates to the currently installed features" option, which is the default.
*** Bug 166698 has been marked as a duplicate of this bug. ***
Re-marking this as a blocker. For a user going through the default options when updating this results in a broken Eclipse install since feature dependencies are not obeyed. Also see discussion at this somewhat old post: http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg00381.html
*** Bug 167277 has been marked as a duplicate of this bug. ***
*** Bug 140473 has been marked as a duplicate of this bug. ***
Adding my +1 vote too. Mik or William, if you can reproduce this "multiple update searches required" effect for a multi-project-dependent update like, say, GMF, TPTP, BIRT or WTP, you might get more votes as those communities are probably bigger and more vocal about bad UM experiences. ;-) Start with a clean Eclipse, install the M3 code for WTP or TPTP (and its dependencies, EMF, VE, GEF, UML2, etc.) then wait a couple weeks and try updating to M4. (Or use two different I versions, or Callisto 3.2 -> 3.2.1, etc.) If this effect is seen there too, it's a usability issue for Europa, not just Mylar, and thus ought to move up to P1 priority and actually get looked at before its 1 year birthday passes. ;-)
See also bug 167235.
Update: I just tried to reproduce installing a WTP 1.5.0 All-in-one, executing search for updates..., and it surprise: it works... I think there is something particular on Mylar scenario; I'll narrow my tests until get the exact scenario for this bug.
I think I got very close to the solution to this problem. I made some update-site scenarios: - plugin com.test.plugin1 - plugin com.test.plugin2 - feature com.test.feature1 containing com.test.plugin1 - feature com.test.feature2 containing com.test.plugin2 1 - In my first scenario, com.test.feature1 depends on com.test.feature2: - On a clean Eclipse 3.2.1 installation, add the update site: http://www.willianmitsuda.com/files/bug-132450/feature-dependency-base/ and download the 2 features. - Restart Eclipse. - This will install 1.0.0 version of the features. This update site is also only a bootstrap site; the installed features have http://www.willianmitsuda.com/files/bug-132450/feature-dependency-test/ hardcoded as discovery sites, so if now you select "Search for updates on installed features", it will search for the 1.0.1 version in that place. - However, surprise: it will present a update for 1.0.1 version of the 2 features! Strange, no? Considering this bug story, it should present only feature2 update. Having said that, I took a look at the Mylar features source code, and I saw that for some unknown reason, the dependent features depends on not the base feature, but also on its plugins. I.e.: org.eclipse.mylar.bugzilla-feature depends not only on org.eclipse.mylar-feature, but also on org.eclipse.mylar.tasks.core, which in included on org.eclipse.mylar-feature itself, among other plugins. So I made a second scenario: 2 - com.test.feature1 depends on com.test.feature2 AND com.test.plugin2 plugin: - On a clean Eclipse 3.2.1 installation, add the update site: http://www.willianmitsuda.com/files/bug-132450/feature-including-plugin-base/ and download the 2 features. - Restart Eclipse. - This will install 1.0.0 version of the features. Again, this is only a bootstrap site; the installed features have http://www.willianmitsuda.com/files/bug-132450/feature-including-plugin-test/ hardcoded as discovery sites, so if now you select "Search for updates on installed features", it will search for the 1.0.1 version in that place. - Now we get exactly what happens on Mylar: only the feature2 upgrade is offered!!! - If you select "Search for new features..." and change the URL to http://www.willianmitsuda.com/files/bug-132450/feature-including-plugin-test/ it will present the 2 updates. Conclusion: - Apparently, the "plugin as dependency of a feature" is triggering this bug. Mik, is there any reason for this? In any case, can you try to reorganize the Mylar features based only on feature dependency and see if this stops happening? - Afterall, is there a platform/update bug? Is it wrong to this dependency configuration be triggering this behavior? Or is this right, and there is something missing if you want to use plugin dependencies? If there is anyone from platform/update listening, can you please point us to some explanation about how dependencies are handled?
There have been many bugs about 'select required' not working with plugin dependencies. The fix was to switch to feature dependencies, since UM doesn't do plugins. Some examples: bug 131807, bug 133823, bug 133826, bug 148682, bug 148686. More recently, I opened bug 166374. As far as I know, there's been no work done to advance support for plugin dependency resolution w/ UM, since AFAIK it was never designed to work that way. If someone from Platform > Update is listening and wants to correct me here, please do, and I'll stop speaking on your behalf. ;-)
Nick, thanks for the explanation. It seems it is a very recurrent problem... And too bad that it probably won't be fixed... afterall, it is all user's fault... http://www.jroller.com/page/eu?entry=eclipse_is_you_and_yet At least they could remove the "add plugin" button on PDE feature dependency editor, so the users stop using a broken feature... I can provide a patch on this :)
'Add Required' button is there to try to help you but it cannot do wanders. Feature to feature dependency is clear and fairly easy to handle because the function can look for the features that are missing in the site (it will have to recursively resolve their dependency but we do that). Feature to plug-in dependency is harder because there may be more than one feature that include that plug-in. I think that Branko fixed cases where feature->plug-in dependency still points at a single feature to check. I don't know what happens when there are more than one. Perhaps that is your problem. Branko, can you comment on the limitations of 'Add Required' when features prereq plug-ins?
(In reply to comment #22) > Feature to plug-in dependency is harder because there may be more than one > feature that include that plug-in. Note that you can have the same problem with feature->feature dependency as well: a required feature can be included in several other features, and it can be that the site.xml file doesn't explicitly list the required feature but only several choices of "wrappers" which all include the feature. UM should select the minimal possible dependency in this case, see bug 154505 (and other similar ones - it's really a big issue for Europa, since Europa tends to have features listed in coarse granularity only). So I think the issue of finding a "small container" for a required bundle or feature should be addressed anyways. The minimum that UM must do (and this is documented in bug 154505), is when a feature is listed both explicitly and contained in a wrapper, the explicit dependency must be chosen.
*** Bug 181853 has been marked as a duplicate of this bug. ***
*** Bug 167235 has been marked as a duplicate of this bug. ***
Could someone from Platform please put some attention to this? I don't normally raise the priority of others' bugs, but this has been ignored for too long. Either it needs to be addressed or the "Search for updates to the currently installed features" should be *removed* from the UI. It regularly causes broken installs, and will cause even more fallout with Europa. Fyi, Mylar we again tried to work around it without success (specifying dependencies and the plug-in level only, at the feature level only, and both). The following bugs are probably related: * bug 175004 Select required fails for dependencies expressed on bundle level * bug 154505: Select Required chooses SDK instead of Runtime
+1 for removing from UI. I've never used the "search for updates..." because I consider it unreliable. I always use "Search for new features" which searches for new features *AND* updates for installed features. It is very unlikely that someone will have enough resources to touch the UM in 3.3 timeframe, and for 3.4 the focus will be on the new provisioning effort.
Mik, I appologize for the long period of silence. At the moment, the new development in this area is in the Provisioning effort, and Install/Update has lost most of its committers (I am the only one with some knowledge of Update's inner workings and can only sporadically look at it, if at all). Nevertheless, this seems like an important problem to address. Can community give a hand here? I would appreciate if somebody did the investigation and suggested possible fixes (this is open source, right :-). The more I need to spend time on this one, the less I can spend on other P1 Update defects. More generally, I would appreciate help from the community in making Install/Update usable until we are ready to switch to the new and shiny provisioning solution.
(In reply to comment #27) > +1 for removing from UI. > I've never used the "search for updates..." because I consider it unreliable. Searching for new updates should be the most natural path for users. The right thing to do is to make it reliable.
(In reply to comment #29) > (In reply to comment #27) > > +1 for removing from UI. > > I've never used the "search for updates..." because I consider it unreliable. > > Searching for new updates should be the most natural path for users. The right > thing to do is to make it reliable. > Totally agree, though if it can't be done relatively quickly, then the right thing to do is to remove it since it will cause more confusion and errors if left unfixed much longer.
(In reply to comment #19) There was a question in the comment #19 regarding Mylar features using both feature and plug-in dependencies. Mik, can you answer this question?
(In reply to comment #28) > Nevertheless, this seems like an important problem to address. Can community > give a hand here? I would appreciate if somebody did the investigation and > suggested possible fixes (this is open source, right :-). Dejan: I would be happy to provide a patch that would get rid of the "Choose the way you want to search for features to install" screen so that the wizard takes users directly to the "Select update sites to visit.." screen. Like you I have to prioritize my contributions to Mylar and to the Eclipse SDK based on our user communities' needs, and this would resolve 95% of the problems Mylar users experience with updating. I also think that it meets the common update use case better, since it will allow users to select sites instead of searching for updates to the entire SDK (and possibly Europa) each time. This would leave a problem with the "Automatic Updates" getting into this state, but thankfully that option is off by default so it tends to be used by users who are capable of diagnosing update failures. It also leaves the concern that there is a single problem underlying bug 175004, bug 154505, and the source of this bug. If you are able to solicit community contributions to identify and solve that problem that will be fantastic. It seems to me that such an effort would benefit with guidance of someone on Platform because it has been tricky enough for Platform to address. (In reply to comment #31) > There was a question in the comment #19 regarding Mylar features using both > feature and plug-in dependencies. Mik, can you answer this question? I will look into this again to see if I missed anything when applying Willian's suggested changes. We have had a strict policy of using the plugin.xml editor's "Dependencies (tab) -> Compute (button)" feature, so it is possible that the plug-in dependencies crept in during my testing, since PDE adds those automatically if the corresponding check-box is enabled.
(In reply to comment #32) > I also think that it meets the common update > use case better, since it will allow users to select sites instead of searching > for updates to the entire SDK (and possibly Europa) each time. I like this too, since I usually only want to search for updates to one or two features, and it's currently painfully slow as it pops up 8 prompts for which update sites and mirrors I want to use. Hopefully such a fix would be released for the 3.2 stream as well, since that is what I'm stuck using for now.
(In reply to comment #33) > I like this too, since I usually only want to search for updates to one or two > features, and it's currently painfully slow as it pops up 8 prompts for which I think you can Help > Software Updates > Manage Configuration, then select a particular feature and click the "Scan for Updates" hyperlink on the right hand side. It can only be chosen for parent features (naturally, because updating an included feature would invalidate the parent), and I can not say 100% for sure whether it actually works. But I agree that choosing an update site for checking is better than chosing a feature for checking (since you might need to select multiple features).
All bugs that are referenced in this bug are now fixed or otherwise resolved, and Mik claims that feature + plug-in dependency may be a fluke. Can we give it another try with the next integration build (it will contain all the fixes), and also remove the plug-in dependencies from Mylar features at least for now? Plug-in dependencies are not affecting 'Add Required' button (verified), but may affect search for Updates of the installed features.
(In reply to comment #35) *Great* to hear that the references bugs are resolved. I'll test as instructed once I notice the new integration build go up.
(In reply to comment #35) > All bugs that are referenced in this bug are now fixed or otherwise resolved Ok ... so, some of us (well, me) need this spelled out for us. What is the recommended way to specify 'requires' in our features? Plugins? Features? Or, neither needed, it's all figured out from bundle manifests?
(In reply to comment #37) > (In reply to comment #35) > > All bugs that are referenced in this bug are now fixed or otherwise resolved > > Ok ... so, some of us (well, me) need this spelled out for us. What is the > recommended way to specify 'requires' in our features? Plugins? Features? Or, > neither needed, it's all figured out from bundle manifests? (Just so Dave doesn't feel alone, I'll throw up my hand too. ;-)
Theoretically, both is acceptable. Products like to use feature prereqs because it prevents for viral 'updates' (a rogue feature introducing a newer plug-in that breaks the product). OSGi folks like to live dangerious and they claim that you should not care where the plug-ins is coming from as long as it satisfy your prereq. Again, theoretically both is fine. In practice, we may have some glitches with plug-in dependencies. I don't think we have them in the Install wizard any more, but there may still be some in search for updates. My suggestion to Mik was merely tactical - if you don't need plug-in dependencies, remove them to start working in the short term. If you DO need them, we need to diagnose and fix the bug(s).
I tested the following with I20070417-0800-win32 (for details see Willian's comment#19): * Set up a test update site and set all Mylar features to use that as their update site. * Set all Mylar features to have only features in their Dependencies -> Required Features/Plug-ins list (i.e. removed all plug-ins automatically added by the "Compute" button or the "Recompute when feature plug-ins change" check box). * Ran an update in I20070417-0800, then updated and pushed the Mylar features to the test site and ran another update. I then ran the "Search for updates" three times and each time it *correctly* suggested to install all features and the install completed successfully, for the first time ever! I had followed these exact steps soon after Willian originally posted them, so I am assuming that the recent Fixes Dejan cites fixed the bug. There is also the chance that the automatic compute snuck in during my previous testing without my noticing, but that seems less likely. But it would be worth testing this against 3.2 in case the "feature only" dependencies do the trick there (I'll try to do that in the near future). I'll continue using the "feature only" dependencies with our next few dev builds to ensure that this success can be repeated. If so, it is excellent to see this resolved. If the "feature only" dependencies are the right thing for features, should the PDE avoid getting people into this state by automatically adding plug-ins as dependencies?
(In reply to comment #40) > If the "feature only" dependencies are the right thing for features, should the > PDE avoid getting people into this state by automatically adding plug-ins as > dependencies? > I agree. Plus, I think the versioning guidelines at http://wiki.eclipse.org/index.php/Version_Numbering should be changed. The current advice under "Versioning features" and it's associated example advocates requiring plugins instead requiring features, but that sounds either wrong or highly over simplified. Sounds like the rule should be "if you want to work with update manager, use 'feature requires' ... if you don't need to work with update manger, you can use 'plugin requires' to avoid the brittleness of .... " The other oversimplification in that document, from those "OSGi folks who like to live dangerous and ... not care where the plug-ins is coming from as long as it satisfy your prereq" is that there is no (easy) way (that I know of) to "require" things like the correct docs and help bundles?! So .. back to features for me! Hopefully we'll have something to put on 'staging' in a week or so, just to verify that works again.
Ok, I followed the advice I usually give others, and updated http://wiki.eclipse.org/index.php/Version_Numbering#Versioning_features Feel free to fix my fixes.
I just confirm that I ran "Search for updates" on a I20070418-1012, Mylar 2.0.0.v20070420-0030, it proposes to install 2.0.0.v20070421-0200. The sandbox feature was not proposed, but this is Mylar's fault, I filled bug#183505 for this. Mik, did you try to make a test before you changed the feature dependencies (this time, not the other test months ago)? So we can know if this is working now because of UM changes, not because you missed something on the first test.
(In reply to comment #43) > Mik, did you try to make a test before you changed the feature dependencies > (this time, not the other test months ago)? > So we can know if this is working now because of UM changes, not because you > missed something on the first test. No, I didn't have time to do that so we still need to confirm whether it's the recent fixes that did this or whether this can be worked around on earlier versions (e.g. 3.2) purely by ensuring that only features are specified. I won't have time to do that this week. Jakub: if you are working on this, I think that there needs to be a small test environment that has dependencies specified as plug-ins only, plug-ins + features and features only. Note that I also didn't verify whether I20070417 will do the right thing even if plug-ins are specified as dependencies of features. Dejan, Wassim: do we need a PDE bug for this? If for specifying plug-ins as dependencies of features breaks Update, a lot of integrators are bound to be burned by this very difficult to diagnose bug. For 3.3 I think that either Platform/Update should be updated to address this, or PDE should be updated to avoid to avoid adding plug-ins as dependencies of features or at least issue a warning of the consequences of doing this (assuming the current diagnosis proves correct).
>PDE should be updated to avoid to avoid adding plug-ins as dependencies of >features or at least issue a warning of the consequences of doing this Adding plug-ins as dependencies of features is legitimate and long-standing. The SDK features, for instance, have such dependencies. Such dependency relationship is specified in the feature.dtd since 2.0. The tooling (PDE) should not prevent the user from adding plug-ins nor warn about such plug-ins.
Not sure if this information should help, but: - I made a test on my work machine, with Eclipse 3.3 I20070410-1043, Mylar 2.0.0.v20070417-1400. It proposed to upgrade all features to Mylar 2.0.0.v20070421-0200 and worked perfectly. - Also, I made a test with a 3.3 M6 installation + Mylar 2.0.0.v20070404-1330, and "Search for updates" didn't work.
As documented in bug 106804 comment 33, I can confirm that as of 3.3M7, UM does resolve feature-to-feature-to-plugin and feature-to-plugin dependencies with 'Select Required'. Congrats to the UM team! ;-)
Mik, I tried to use "Search for updates..." on Eclipse 3.3 M7, having Mylar 2.0.0.v20070511-2100, trying to update to Mylar M3, but it only offers me to upgrade the task list and usage report features. Trying "Search for new features..." works well as always. So, it appears this is not fixed yet.
Yes, I noted this too. I hope that it is because Mylar 2.0M2 specified plug-ins for feature dependencies, whereas Mylar 2.0M3 has been updated not to do so. So the assumption there is that the behavior and fix that was done on update manager uses the dependencies specified by the old version of the plug-in, not the one it's about to download. Not knowing the internals I don't know if that's the case, but it makes sense because at the time that the update is running the new features (and new dependencies) have not been downloaded yet. We've already run successful update site mock-up tests of this, so now we have to wait until the next Mylar releases (June 15th) to double check that it works with the usual update sites.
*** Bug 186983 has been marked as a duplicate of this bug. ***
*** Bug 186989 has been marked as a duplicate of this bug. ***
*** Bug 186941 has been marked as a duplicate of this bug. ***
*** Bug 187057 has been marked as a duplicate of this bug. ***
(In reply to comment #49) > Yes, I noted this too. I hope that it is because Mylar 2.0M2 specified > plug-ins for feature dependencies, whereas Mylar 2.0M3 has been updated not to > do so. So the assumption there is that the behavior and fix that was done on > update manager uses the dependencies specified by the old version of the > plug-in, not the one it's about to download. Mik, I don't see the point. My installation is not using Mylar M2, but dev-build 2.0.0.v20070511-2100 from last week, so this problem shouldn't happen right?
(In reply to comment #54) > Mik, I don't see the point. My installation is not using Mylar M2, but dev-build > 2.0.0.v20070511-2100 from last week, so this problem shouldn't happen right? Forgot that you had the dev build and not M2. I think you're right, if this bug is fixed the update should have happened correctly. The only change I have made to our features since the testing is to specify that the feature match should be "Perfect" and not just "Greater or Equal", hoping that would help avoid similar bugs. So as far as we can now tell this bug is not fixed. And despite our always having bold text on our download page not to use "Search for new features.." lots of people are still hitting it whenever they update and get a broken install, as visible by the 4 duplicates that came in today. Does anyone using the Update Manager have any other experiences to add? It is scary to think what will happen if this goes out with 3.3 because a lot of people will get the impression that non-SDK plug-ins are flaky if everytime they update to significant changes they get a broken install. Has anyone on Platform tried to replicate this bug?
We discussed this on the Europa (cross-project-issues) call. Nick Boldt will set up a test environment with EMF to see what results he gets. I will create a patch that encourages users to avoid hitting this bug without removing the "Search for updates.." functionality alltogether, by adding the following: 1) Help -> Software Updates -> Feature Updates wizard page: * Under "Select this option" add a label "NOTE: this can require running update multiple times to install all features." * Rename "Search for new features to install" to "Search for features to install" * Make "Search for new features to install" the default (many users won't read the note even if we make it caps/bold, and seasoned Eclipse users already know to use this setting). 2) Preferences -> Install/Update -> Automatic Updates * If user checks "Automatically find new updates and notify me" pop up a message dialog with: "Note that you may need to run update multiple times to install all features. Use Help -> Software Updates -> Search for features to install to ensure you get all features." Dejan: I believe that without a fix or workaround for this bug, this is the minimal thing needed to keep Eclipse newbies from frequently ending up with broken Eclipse installs when they get Europa-based or other updates. I think its critical that we do something because a rational new user's reaction is to assume that the offending features are broken and uninstall them, not to assume that the update mechanism is broken. I plan on creating this patch tomorrow; please comment if you see any problems with this approach.
What makes me sad is that a lot of effort has been spent to work around the bug rather than fix it properly. So far nobody tried to investigate how to fix this so that only one update pass would do.
Question: Since installed features provide Update sites from which the 'search for updates to existing features' runs, and these sites are ALSO added to the UI for 'search for new features', why do we even need the former? The latter option works fine - and as of M7 actually resolves plugin dependencies. Seasoned users already use the second option because the first option is prone to problems and (for some of us) has never worked as expected. Would it be possible to just hook into THAT second framework for doing automated updates? Why do we have one option that's supported / gets fixed and another that causes pain, is left to die, and is ultimately redundant? As it is, you have to use the 'search for new' UI to check/uncheck the sites you want to be scanned for updates automatically, so the workflow is already broken (or at least this was the case the last time I played w/ the 'search for updates to existing features' UI). I'd propose that the issue here is really just one of usability, so if we remove the option that doesn't work properly and rework the workflow / text labels / options in the one that does, we'll remove confusion, bugs, and usability issues in one fell swoop. (That said, we still need someone to write the patch, if people agree with me.) ;-)
*** Bug 187291 has been marked as a duplicate of this bug. ***
*** Bug 187212 has been marked as a duplicate of this bug. ***
I cannot answer without knowing the extent of the problem. I firmly beleive that having two choices has value. The former (updates) requires minimal user intervention (just find updates and patches for the stuff I have installed). The other one requires more clicks and means 'what else is there for me to install'. We should not mix the value of having these two choices with the current quality of function and the fact that one is buggy and the other is, well, less buggy :-). So far nobody actually went into the code and found the lines of code and classes that are the culprit. One of these days I will get sufficiently annoyed to dig into the code and fix this, or at least see if the fix is more complex that the proposed new dialogs, UI changes, new messages etc. But if I do that, it leaves much to be desired about the Eclipse community and the model in which 'you just go and fix the problem that bugs you'.
*** Bug 187219 has been marked as a duplicate of this bug. ***
(In reply to comment #61) > I cannot answer without knowing the extent of the problem. I firmly beleive > that having two choices has value. The former (updates) requires minimal user > intervention (just find updates and patches for the stuff I have installed). > The other one requires more clicks and means 'what else is there for me to > install'. We should not mix the value of having these two choices with the > current quality of function and the fact that one is buggy and the other is, > well, less buggy :-). I agree with this.
(In reply to comment #61) > But if I do that, it leaves much to be desired about the Eclipse community and the model in which > 'you just go and fix the problem that bugs you'. Dejan: I'm having trouble in deciphering whether your "just fix it yourselves or I'll do it if it annoys me enough" comment is meant to be intentionally dismissive or not, so I'll assume it's not. In my opinion this is not a problem that Platform/Update can expect someone to jump in and fix. I apply dozens of patches each month on Mylar and I would never expect someone to provide a patch for a problem that's deeply buried in the internals of a problematic component without holding their hand and helping out on the coding. It's just too hard to know whether a proposed fix would cause other problems without being up-to-speed on that component. I am happy to put some time to this because every release we get constant complaints and duplicates of this bug (like the 7 that came in since we released Mylar 2.0M3). But as I said in comment#32 I can not justify putting an indeterminate amount of time towards learning Platform/Update internals because that would take away from our Europa plan and because Mylar users have more need for items on our plan than on proper "Search for new updates" functionality. I assume that Platform has a bigger incentive to do something about this because this bug is bringing down the overall perceived quality of the Platform, not just one component. > I cannot answer without knowing the extent of the problem. Then please consider investigating the extent of the problem. I have done it to the best of my ability without taking on having to understand Platform/Update internals and come up with the following definition of its extent: 1) "Search for updates": FAILS every time Mylar users update. 2) "Search for new features": WORKS every time Mylar users update. Hopefully Nick's investigation can provide more insight and see if it breaks regularly for EMF. I will take another stab at figuring out why it worked in the Mylar test environment when we removed all plug-ins from the feature's dependencies list. As you and David have pointed out there is value in a "Search for updates" feature, but unless there is a clear way for other projects to ensure that they don't trigger the partial install, and it is happening regularly, this is a bug, not a feature. If that's the case and there is no fix made to the core functionality please let's not let 3.3 go out with the broken behavior as the default, and let's inform the users of the consequences.
(In reply to comment #64) Mik, I have made it clear in the recent past that update has currently 0 active contributors and for anything to happen, the community needs to pitch in. I understand the difficulties in debugging the complex Update internals particularly when on a tight schedule with your own component. Nevertheless, this problem is around long enough and the proposed workaround does not sound trivial (changing the UI, adding new messages and dialogs etc.). Update is still a regular Eclipse component with source and can be debugged in a standard way - I don't understand the resistance to giving it couple of rounds in a debug mode. Note also that all the other defects referenced in this bug are now showing as fixed. In other words, we are putting our money where our mouse is :-). Other people contributed patches, we released them, we also fixed a number of problems ourselves (and when I say 'we', that's really me :-(. In this particular case, a bit of debugging could go a long way - just getting closer on a possible reason for differences in behaviour. I didn't even ask for a patch - just some good will and couple of hours of debug time. Willian did provide valuable information about plug-ind dependencies. I still stand by my dissapointment re open source ideals vs reality. Here we have a code base with the lack of committers, a hard problem that is affecting people, and an open source model that makes it easy to investigate and contribute a fix, yet all we are collectively doing for months is staring at it and adding appends that amount to 'yup, it is still a problem'.
(In reply to comment #63) > (In reply to comment #61) > > I cannot answer without knowing the extent of the problem. I firmly beleive > > that having two choices has value. The former (updates) requires minimal user > > intervention (just find updates and patches for the stuff I have installed). > > The other one requires more clicks and means 'what else is there for me to > > install'. We should not mix the value of having these two choices with the > > current quality of function and the fact that one is buggy and the other is, > > well, less buggy :-). > > I agree with this. Maybe somebody can help me understand something here: We have a feature that reliably breaks peoples' Eclipse installs. We seem to agree that nobody has the resources right now to fix the feature so that it doesn't break peoples' Eclipse installs. It seems to me that the above is the usual scenario that applies when an organization simply removes a feature from a product. In the case of Platform/Update, this simply would involve commenting out a few lines of code that display the offending radio button. "But the UI would be ugly because that step in the wizard would have exactly one radio button and 'next' button--introducing an unnecessary step in the wizard." I claim that this is less bad than the product having a feature that breaks peoples' installs. Or am I missing something? Somebody please help me understand what's going on here. Thanks in advance.
I spent some time this afternoon debugging. I think I know what the reason is. Feature1 depends on Feature2. Since updates are validated independently, the 'before and after' analysis reveals that installing Feature1 1.0.1 would not work because it requires Feature2 1.0.1 and at that point it is not installed. That is the only reason. Updates to both Feature1 and Feature2 are correctly found, but they need to be validated as a batch in order to pacify the validator nanny. Here is the actual validation error: [Status ERROR: org.eclipse.update.core code=1 Feature1 Feature (1.0.1) requires feature "com.test.feature2 (1.0.1)", or compatible. null] In contrast, all selected features are validated in a batch when going though the new feature install.
Here is the proposed fix: I added the notion of 'automatic' update to the UpdateSearchCategory. When this flag is true (default), each individual update will be independently validated. Thus manual, command line and scheduled updates will be as before. When invoked from the wizard, 'automatic' flag will be false and individual validation will be skipped. This works because the hits will be passed to the review page (the same page you arrive after searching for new features to install), and validation is performed anyway when these hits are checked or unchecked. With this patch applied against update.core and update.ui, Willian's test case passes (Feature1 and Feature2 can be installed using 'Search for Updates' in one pass).
Created attachment 67538 [details] The proposed patch
Created attachment 67539 [details] Replacement Update Core with the patch
Created attachment 67540 [details] Replacement Update Ui with the patch applied
Willian, Mick, please take the attached Update Core and Update UI and replace the corresponding files in your Eclipse builds. Please verify that: 1) The test case in this bug indeed passes 2) Mylar updates can now be picked up by the 'Search for Updates' option
(In reply to comment #64) > 1) "Search for updates": FAILS every time Mylar users update. > 2) "Search for new features": WORKS every time Mylar users update. > Hopefully Nick's investigation can provide more insight and see if it breaks > regularly for EMF. Unfortunately, I cannot reproduce this for a number of reasons: * EMF ships with a pointer to our update site, which contains ONLY our release builds. * 'Search for updates' ONLY checks that site, even if I install EMF from the Europa Discovery site or EMF's own site-interim.xml. * 'Search for new features' of course works fine, because I can tell UM to search the Europa or site-interim.xml sites, where it finds features and can install them; however, that's not the issue here. I was able to use 'Search for updates' to update GMF from M5 to M6a successfully, since they've got a great hack in place that I'll try with EMF later on. The hack is this: The update site referenced in the GMF runtime feature is http://download.eclipse.org/modeling/gmf/update-site/releases/site.xml. So, logically, that's the one Eclipse will check for updates. HOWEVER, Max had accidentally set the mirrorsURL to their milestone site instead: http://download.eclipse.org/modeling/gmf/update-site/milestone/site.xml If I'm not mistaken, this allows a workaround for the above issue, "'Search for updates' ONLY checks that [release builds update] site". I'll find out tomorrow.
(In reply to comment #73) Oh, and BTW, I've opened a number of related bugs that I encountered in trying to get to the point of being able to install via UM and then check for updates to GMF and its dependencies. See: bug 187410, bug 187406, bug 187396.
(In reply to comment #72) > 2) Mylar updates can now be picked up by the 'Search for Updates' option > I tried, but it didn't work. But I think your idea on comment#67 is right. If found another simply test case: If you open the "Manage Configuration" option, right-click "Mylar Task List" feature, who doesn't depend on another feature, select "Find Updates", it finds it. But you do the same to "Mylar Connector: Bugzilla", who depends on "Mylar Task List", it does not find anything. I hope this information helps.
(In reply to comment #72) > 2) Mylar updates can now be picked up by the 'Search for Updates' option Dejan: I was able to verify that I20070515-0800 without your changes continued to fail, but that after I used your updated plug-ins "Search for Updates" succeeded. Before I get too excited we should have Willian verify my steps. Willian: I was seeing exactly what you report in comment#75 but then noticed that Dejan's new plug-ins are numbered ..200705161803 not ..v200705161803 so they were not being used (since 'v' is bigger than '2' and the old plug-in versions use the 'v'). Please try to delete the old ..update.core and ..update.ui, copy in the new ones, run Eclipse with -clean, rinse, lather, and repeat. For testing I have put up a 2.0.0.v20070513-1500 build of Mylar at http://download.eclipse.org/technology/mylar/update-site/dev/test . It's almost identical to the ../update-site/e3.3 version but has the older version number. All features have their update sites pointed to ../update-site/e3.3.
(In reply to comment #76) > Willian: I was seeing exactly what you report in comment#75 but then noticed > that Dejan's new plug-ins are numbered ..200705161803 not ..v200705161803 so > they were not being used (since 'v' is bigger than '2' and the old plug-in > versions use the 'v'). Please try to delete the old ..update.core and > ..update.ui, copy in the new ones, run Eclipse with -clean, rinse, lather, and > repeat. Yes I noted this too. What I did was to delete the old ones and rename the jars Dejan provided to the appropriate names, and restart with a -clean, just for sure. > For testing I have put up a 2.0.0.v20070513-1500 build of Mylar at > http://download.eclipse.org/technology/mylar/update-site/dev/test . It's > almost identical to the ../update-site/e3.3 version but has the older version > number. All features have their update sites pointed to ../update-site/e3.3. > I'll take a look.
Just to make sure, I made a clean test at my home machine: - Used a clean installation of Eclipse 3.3 M7. - Installed the dev-build of Mylar, 2.0.0.v20070511-1630 using "Search for new features". - The URL is http://download.eclipse.org/technology/mylar/update-site/dev/e3.3 - This build points to the official update site, so if run "Search for updates", it won't bring all features available. Dejan, if you want a test environment to debug, just to make sure your fix was correct, please try the previous steps. Then I removed the update.core and update.ui plugins, restarted Eclipse with a -clean. The first time I ran "Search for updates" it brought me a mysterious NullPointerException: Error Thu May 17 00:48:16 GMT-03:00 2007 An internal error occurred during: "Update Manager". java.lang.NullPointerException at java.io.FilterInputStream.close(FilterInputStream.java:155) at org.eclipse.update.internal.core.connection.HttpResponse$MonitoringInputStream.close(HttpResponse.java:51) at org.eclipse.update.internal.core.SiteURLFactory.createSite(SiteURLFactory.java:97) at org.eclipse.update.internal.core.InternalSiteManager.createSite(InternalSiteManager.java:334) at org.eclipse.update.internal.core.InternalSiteManager.createSite(InternalSiteManager.java:326) at org.eclipse.update.internal.core.InternalSiteManager.createSite(InternalSiteManager.java:291) at org.eclipse.update.internal.core.InternalSiteManager.attemptCreateSite(InternalSiteManager.java:222) at org.eclipse.update.internal.core.InternalSiteManager.getSite(InternalSiteManager.java:162) at org.eclipse.update.core.SiteManager.getSite(SiteManager.java:80) at org.eclipse.update.search.UpdateSearchRequest.searchOneSite(UpdateSearchRequest.java:452) at org.eclipse.update.search.UpdateSearchRequest.performSearch(UpdateSearchRequest.java:299) at org.eclipse.update.ui.UpdateJob.runUpdates(UpdateJob.java:207) at org.eclipse.update.ui.UpdateJob.run(UpdateJob.java:168) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) But after that, and on all other attempts, it brought me all the features correctly, so it works ;) There is a possibility that I made some mistake on my previous test, but it was on my work machine. I'll try to recheck there tomorrow.
OK, sorry about the version number (it was only meant for quick testing, I will submit to the RC1 build today). I also added a null check that will hopefully fix the stream NPE that you are getting and that Mik reported in a separate bug. I will release the bug into RC1 today (unless DJ violently objects to the patch :-) and let you know when you can pick the build and retry.
I made another test on my work machine and it worked. Previously, I renamed the old jars and put the new ones with the old names, but it didn't work (I don't understand why... it looks like it was getting the old plugin code from some cache...). Today I simply deleted the old ones, put the new ones, and restarted with -clean. This way it worked...
Yes, but did you 'rinse, lather, and repeat' as Mik suggested? Without rinsing, Eclipse gets soggy and has no fullness and body :-).
Released into the RC1 build. Please keep an eye on the builds today and verify when available.
Wow, this is truly excellent news. It sounds like we can rely on a functioning Update Manager that will carry us through 3.3 and onto whatever the new provisioning work brings. Dejan: now that we can trust the core facilities, for any bugs that we find via Mylar we will make an attempt to investigate/patch ourselves. I realize how challenging your position with having no committers on this component is and I know that a lot of users will appreciate the key fixes that you've made for 3.3. The only remaining bug I've filed that might warrant our attention for 3.3 is bug 107280, bug 117319 can probably be closed now. I'll comment further on those bugs.
Just to clarify ... does this change the advance that for Europa, we should specify "requires feature", instead of "requires plugin"? Is that a separate issue?
(In reply to comment #84) > Just to clarify ... does this change the ==> advice <== that for Europa, we > should > specify "requires feature", instead of "requires plugin"? Is that a separate > issue? >
I have removed premature validation done during the search. This means that the two code paths are now very similar and validation is peformed during user selection in the install wizard. Since this validation has been confirmed to work with plug-in dependencies, I think we can relax that constraint. In a nutshell, this is what you have now: 1) If you choose 'Find new features to install', you need to pick the sites to search and you will get all the features in all the sites 2) If you choose 'Find updates to features you already have', you will immediately end up in the list of hits but the hits will be limited to updates to features you already have. In both cases, you will be able to individually select features to install and identical validation is applied to both.
(In reply to comment #83) > Wow, this is truly excellent news. Thanks, Mik. As an Eclipse veteran, I have an involuntary reaction to a bug and feel the urge to fix it but there is only so many hours in the day. Update is trickier to debug than most platform components (it even requires a special self-hosting setup), and I do have an advantage of knowing the code base better than many people. As for bug 107280, it does not seem like Update to me - I added a comment.
Dejan, thanks for doing this!
Please verify the fix using RC1 candidate build I20070517-1700 so that I can declare a GO today.
OK, cannot wait - I tested Willian's test case and it passed. If there are any problems with Mylar, please reopen to revisit in RC2.
Sorry for the delay. I tested and it is OK! Thanks for resolving this Dejan!!!
Great. I almost had a heart attack when I tried your example today and while it found both Feature1 1.0.1 and Feature2 1.0.1, I didn't get any errors when checking only one of them as usual. Fortunately I picked the wrong site URL (the one with independent features). When swapping URLs, I got my errors. Talk about last-minute terror :-).
Testing w/ RC1 candidate, I updated from M5-level features to M7 (in two steps, just to see if anything wierd happened). This includes GMF, GEF, OCL, QTV, UML2, EMF & XSD: all worked great. Thanks!!! Also played around with policy files and as a side note, they work pretty well for this sort of testing (allowing you to use live update sites w/o having to cobble anything wierder together than a single XML file, because you can override the URL of the sites used for the updates). If you've never used 'em, see details here: http://wiki.eclipse.org/index.php/Testing_Pre-Release_Builds_Via_Policy_Files
Interesting. We actually added policy file support for a different reason: we wanted admins to mirror external update sites (using the command-line site mirror utility) and then create a policy file that redirects updates to this local LAN update mirror. This would allow a company with many licenses to redirect updates of many MBs from the internet to the local LAN. They could also choose which features to mirror in case certain versions are not supported yet. So this is a novel use of the policy file - cool.
*** Bug 187344 has been marked as a duplicate of this bug. ***
*** Bug 187929 has been marked as a duplicate of this bug. ***
*** Bug 190446 has been marked as a duplicate of this bug. ***
Is this fixed? When will this be released. There is no way of going back in the Updates dialog box when a dependency is required.
Created attachment 98311 [details] Eclipse 3.2 No back button Not being able to select the dependencies required
Based on the timestamps in this bug it looks like this was fixed in Eclipse 3.3, not 3.2. Please upgrade.
I am using Eclipse Platform Version: 3.3.2 Build id: M20080221-1800 I am still experiencing the issue
(In reply to comment #101) > I am still experiencing the issue The error shown in your screenshot says that Mylyn 2.3.1 requires Eclipse 3.4, so clearly the issue is that you need to upgrade to Eclipse 3.4. Eclipse 3.4M7 is out in the next day or two. Try that. Or try an older Mylyn which is compatible w/ Eclipse 3.3.2. Details should be on their website: eclipse.org/mylyn.
I am not talking about Mylyn . The screen does not allow me to go back nor it selects the dependencies automatically. Please review the screen. It should either allow users to go back and select the dependencies or auto-select the required items
(In reply to comment #102) > The error shown in your screenshot says that Mylyn 2.3.1 requires Eclipse 3.4, > so clearly the issue is that you need to upgrade to Eclipse 3.4. Or install Mylyn 2.3.x for Eclipse 3.3...
The issue is not about Mylyn! Please read the issue. It is about : update searcher should compute the dependencies, and being available, update all features only once, not requiring this "2 phase update"
Where has the issue been resolved?
AFAIK, this issue has been fixed in 3.3. I guess the bug you are experiencing is not the same. Do you have the steps to reproduce from a clean install?
