Community
Participate
Working Groups
When using update action in p2 update manager, it updates currently installed features to the new versions, but it don't offer to install newly added features available from the project update site. It is confusing for the end users and they can easily miss newly added features.
I doubt that we would ever interpret "update" as installing new features. The suggestion sounds like it comes from a "producer-driven" point of view where a site producer considers update to mean "take all the new stuff I put on my site." From a consumer point of view, update means "update what I have." We've had requests to remove the ability for users to add new features at all in some product configurations. I'd have to better understand the user/use case. leaving this bug open as it suggests that browsing for available software should be made easier, or that a snapshot of site content should be kept so the user can see what's new on a particular site. I retitled the bug, if you think this misrepresents the original point, feel free to change it back.
Susan, I want to clarify, that "Install" works fine, but number of users get confused about current "Update" behavior. Those users are not necessarily familiar with concepts of features and installable units, and they simply want to pickup new functionality which is packaged as new units. Currently they have to use "Install" to do that and also manually select what update sites to scan for those new features. This somehow making "Update" action not very useful and at at the same time "Install" action is too complicated for an average user and It would be really nice to address this complexity need to be addressed in the update manager UI.
Based on various feedback, it seems that the integration of the available and installed view is causing some confusion. And perhaps this is why your users expect "update" to find new software. But I don't think the solution is to generalize "update" to search for new features. Our current plans are to move the available view into the install wizard and possibly change the default organization to a "show by name" view. This would let users easily see in one command (Install New Software...) all the available software. We also intend to provide single click check for updates. This is shown in http://wiki.eclipse.org/Equinox_p2_UI_3.5_workflows Do the proposed workflow changes address your concerns?
Susan, I don't think this is going to help. Users have no way to know if they need to chose update or install. More over, the "update" is kind of a natural choice from the user point of view if they have installed given "software" (this is a really odd terminology choice). The worst part is that if "software" made some refactorings like splitting some plugins into multiple new ones, the update without fetching newly added features will break user installation.
> Susan, I don't think this is going to help. Users have no way to know if they > need to chose update or install. More over, the "update" is kind of a natural > choice from the user point of view if they have installed given "software" > (this is a really odd terminology choice). I'm having trouble understanding what kind of user we are talking about and what the specific scenario is. What is the user's knowledge, how did the user come to know they needed to do anything? If they read about some "Foo" plug-in and decided, "hey I want to try that." Well, they know they are adding something to the system. Or perhaps the user says "Someone told me I need Foo." Maybe they will look to see if they already have "Foo," or perhaps they will know they don't, and choose to add new software. If they think they need to "update to get Foo," they might be temporarily confused by the current behavior, but I don't think we should redefine/clutter "update" to solve this confusion. What about a link on the updates wizard and on the "there is nothing to update" message that says "Click here to look for new software for your system"? The old (3.3 and before) Eclipse Update Manager made this distinction in the first page of the "find and install..." wizard. Did you find this better/more explanatory? If the real issue is that you want to update your users with whatever you have deemed to be the right software for a particular install, and make that part of a "standard update," then you can build metadata that will present these things as updates. > > The worst part is that if "software" made some refactorings like splitting some > plugins into multiple new ones, the update without fetching newly added > features will break user installation. > That's not true. A provider is free to update/refactor the plug-ins all they want. The metadata would need to use the same plug-in id and increment the version number, but beyond that, the rest of the metadata (required plug-ins, etc.) as well as the actual jar files can be refactored/split/merged/renamed as needed.
(In reply to comment #5) > If they read about some "Foo" plug-in and decided, "hey I want to try that." > Well, they know they are adding something to the system. Or perhaps the user > says "Someone told me I need Foo." Maybe they will look to see if they > already have "Foo," or perhaps they will know they don't, and choose to add new > software. "Install" is not a problem > If they think they need to "update to get Foo," they might be temporarily > confused by the current behavior, but I don't think we should redefine/clutter > "update" to solve this confusion. I am not sure what you suggesting to do about "Update". Just moving it into a different menu is not going to solve issue. > What about a link on the updates wizard and on the "there is nothing to update" > message that says "Click here to look for new software for your system"? The > old (3.3 and before) Eclipse Update Manager made this distinction in the first > page of the "find and install..." wizard. Did you find this better/more > explanatory? Unfortunately not. It does not address scenario I am talking about. There is an update, and plugin versions are increased. But in addition to increased versions the new features been added to the update site. Right now, update will find and install new versions, but not the newly added features. To get those new features user have to explicitly use "Install", which isn't exactly obvious. Basically we have to tell users to *always* use "Install", because "Update" won't work. > If the real issue is that you want to update your users with whatever you have > deemed to be the right software for a particular install, and make that part of > a "standard update," then you can build metadata that will present these things > as updates. I am not sure what that mean. From my point of view I've added new features to the update site and generated p2 metadata for the update site. Is there something else need to be done or p2 metadata generator is not generating it correctly? > > The worst part is that if "software" made some refactorings like splitting some > > plugins into multiple new ones, the update without fetching newly added > > features will break user installation. > > That's not true. A provider is free to update/refactor the plug-ins all they > want. The metadata would need to use the same plug-in id and increment the > version number, but beyond that, the rest of the metadata (required plug-ins, > etc.) as well as the actual jar files can be refactored/split/merged/renamed > as needed. Consider case when user had plugin org.foo.xyz v1.0.0 installed. Now feature been split into org.foo.xyz v1.0.1 and org.foo.xyz1 v1.0.1. Currently, after updating user will get new version of org.foo.xyz that had functionality removed, but she won't get the new org.foo.xyz1 feature, resulting in breaking the product installation.
>There is an >update, and plugin versions are increased. But in addition to increased >versions the new features been added to the update site. Right now, update will >find and install new versions, but not the newly added features. To get those >new features user have to explicitly use "Install", which isn't exactly >obvious. Basically we have to tell users to *always* use "Install", because >"Update" won't work. I guess I stand by my first statement in comment #1, that you are viewing "update" from a producer point of view. You want to be able to "push" updates to your user, and this is reasonable, but must be done in the metadata for your site. >I am not sure what you suggesting to do about "Update". Just moving it into a >different menu is not going to solve issue. We are looking at separating the update and install tasks because some users are finding the integrated view too overwhelming, and other users are asking for configurations where only update is provided (because the user has no permission to add new software). I agree it doesn't solve your problem, but I can't solve your problem in a general way. >From my point of view I've added new features to >the update site and generated p2 metadata for the update site. Is there >something else need to be done or p2 metadata generator is not generating it >correctly? If I understand correctly, you want to be able to make changes to your site and have this appear as a single update to users connected to your site. Rather than just generate metadata for atomic features, it sounds like you need to define a higher level "installable unit" in your metadata that describes your users' environment. Then you can increment this IU version and change its requirements to refer to whatever updated plug-ins and new plug-ins you want to appear in the update. What you are running into is that we don't really have tooling that makes this easy. What you are describing sounds like a cool idea - being able to construct "site deltas" that appear as updates. >Consider case when user had plugin org.foo.xyz v1.0.0 installed. Now feature >been split into org.foo.xyz v1.0.1 and org.foo.xyz1 v1.0.1. Currently, after >updating user will get new version of org.foo.xyz that had functionality >removed, but she won't get the new org.foo.xyz1 feature, resulting in breaking >the product installation. The metadata for org.foo.xyz v1.0.1 should define a requirement on org.foo.xyz1 v1.0.1.
(In reply to comment #7) > I guess I stand by my first statement in comment #1, that you are viewing > "update" from a producer point of view. You want to be able to "push" updates > to your user, and this is reasonable, but must be done in the metadata for your > site. I am fine with anything, as long as there are tools provided for producers, and consumers can get additions to the installed features transparently, but at the same time they should have an option to not install new additions. Right now I am not aware of any tools other than PDE site.xml editors and p2 metadata generator application for update site produced by PDE. Those tools ton't allow to work with any installable units other then feature. But even if they would, it doesn't seem your suggestion about changing metadata would work, simply because org.foo.xyz1 could be optional to install, but user who updating product won't know that such feature even exist. All, in all, I still think that it would be a good idea if "Update" action would notify user that there is new features available from the update site they updating from (generally update sites are discovered from already installed features). I don't think this scenario should be mixed with case when someone is not allowed to install new features. I am pretty sure none of our users had issue like that, so it is out of scope for me and should be handled separately. However I am constantly getting reports about breaking installations or missing features and looking for a way to address that.
>I am fine with anything, as long as there are tools provided for producers, and >consumers can get additions to the installed features transparently, but at the >same time they should have an option to not install new additions. <snip> >But even if >they would, it doesn't seem your suggestion about changing metadata would work, >simply because org.foo.xyz1 could be optional to install, but user who updating >product won't know that such feature even exist. Required IU's can be specified as optional. Today they are "greedily" obtained, there is discussion to make this configurable (bug 247099) and allow the user to decide (bug 247342.) >Right now I am not aware of any tools other than PDE site.xml editors and p2 >metadata generator application for update site produced by PDE. Those tools >ton't allow to work with any installable units other then feature. The tools for 3.4 focused on mapping older concepts (features and plug-ins) to p2 metadata, but there is definitely a need for better metadata authoring. For example see http://wiki.eclipse.org/Equinox_p2_Metadata_Authoring http://wiki.eclipse.org/Equinox_p2_Metadata_Repository_Authoring >All, in all, I still think that it would be a good idea if "Update" action >would notify user that there is new features available from the update site >they updating from (generally update sites are discovered from already >installed features). <snip> >I am pretty sure none of our users had issue >like that, so it is out of scope for me and should be handled separately. We have to consider all of the users so we can't adopt a producer-view of software updates when we believe the real answer is in management of your site and your model of what you want your users to see. I think this is an interesting scenario but so far I don't see any new work for us besides the bugs already mentioned above. It sounds like we can support what you want, but you'd like tooling to make it easier to craft the metadata, and a better story for presenting optional dependencies. Agree?
(In reply to comment #9) > We have to consider all of the users so we can't adopt a producer-view of > software updates when we believe the real answer is in management of your site > and your model of what you want your users to see. I don't understand why you call this a producer view? From the user point of view this is a real user issue due to issue with p2 update feature. > I think this is an interesting scenario but so far I don't see any new work for > us besides the bugs already mentioned above. It sounds like we can support > what you want, but you'd like tooling to make it easier to craft the metadata, > and a better story for presenting optional dependencies. Agree? Sorry, I can't agree on that. At least not before someone would show a working example how described scenario could be handled with existing "tools without additional work". For instance, create two update sites that would have two versions of the same feature as described in the previous comments and show that update action can actually pull down new features. That would be a great piece of currently missing documentation generally useful for all p2 users.
I would like to understand what is really the issue being discussed. On one hand the title and some comments talk about the discovery of new features when installing something, for example I install m2eclipse and I should also find about foobar, and on another hand the example talks about the case of a refactoring of a feature into several. To me, these 2 scenarios are disjoints and I would want some clarification wrt which one is really the problem, especially when Eugene says that he is fine with anything :-) > All, in all, I still think that it would be a good idea if "Update" action would notify user that there is new features available from the update site they updating from (generally update sites are discovered from already installed features). One important thing in this discussion is that the provenance of the installable unit is never known. I may install m2eclipse from a CD and still be willing to find updates on my companies server, or the main site. >From the user point of view this is a real user issue due to issue with p2 update feature. Just to set the expectations right, this may be a restriction, but this was not possible in update manager, therefore this is at best an enhancement request. Now wrt the particular usecase, I'm kind of confused on how you achieve the refactoring of a feature in 2 features without breaking the contract you had set in the initial feature. In a sense you are saying in Foo 1.0, you get A and B, and now in Foo 1.1 you only get A. So obviously a newer version of Foo contains less stuffs and installing it will result in what you asked for. Note that if A still had a dependency on the plugin B it would still get installed even though the feature containing B was not installed. To me the only way to not break your users in this kind of situations is for Foo 1.1 to have a dependency on the other feature (like Susan mention in a previous comment) or at least the necessary bits. This is what you would have done with UM and I don't see why this solution would not be acceptable with p2. Could you please develop? I'm trying to understand the real usecase behind this. Also you mention that you may make this feature optional, then how do you guarantee that you are not breaking the user (or any other feature referring to this one) of the initial feature. That said, for the particular problem of a refactoring of a feature into several, p2 offers to each IU the ability to express which other IU it is an update of. Therefore this allows for features resulting of a split to still be presented to the user when looking for updates. Note that even though some of the basic building blocks are in place, this has never been tested and currnetly not officially supported.
(In reply to comment #11) > I would like to understand what is really the issue being discussed. On one > hand the title and some comments talk about the discovery of new features when > installing something... Installing is not a problem. The problem is to find out about new features added to the update site while running an update action. > when Eugene says that he is fine with anything :-) No, I said, I am fine *with anything that works*. Unfortunately the update action does not work and I am yet to see solution for that.
(In reply to comment #11) > Now wrt the particular usecase, I'm kind of confused on how you achieve the > refactoring of a feature in 2 features without breaking the contract you had > set in the initial feature. That is not really relevant to the problem in p2 update manager. To clear your confusion, there is not necessary a contract in plugin A. For example, internal classes could be extracted from plugin A and moved into plugin B that depends on A, so, no API breakage. But now if user won't have plugin/feature B installed, he will lose functionality that been moved out from plugin A. I would think this is quite common scenario when updating from the dev builds. Right now, the only option to get around it is to use "Install" instead of "Update", which is not cool at all and kind of raises the question of usefulness of the "Update" feature.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This issue is stale and there is just no investment in features such as this, especially given that there are a great many bugs that should be fixed first.
