Community
Participate
Working Groups
I wanted to track a use case from a recent democamp... One of the presenters was demoing his RCP app and was trying to express that he really didn't need the sophistication of the p2 UI and it was in fact way beyond what his users could easily understand. What he was looking for was a way to check for updates on his product and if available allow the user to choose to install them. That's it. No revert, no install/uninstall of other features, no managing repos etc. I know Susan did some work on alternate UIs like this so perhaps this is already done however the usecase seemed really reasonable to me so I wonder if we might support a Simple Update UI more formally.
I think we're nearly there already, in that someone could add the "check for updates" command to their RCP app. The other side of this is that his end users (marine biologists and geologists I think), were scared by "big long version numbers" and other scary details in the update dialog. He wanted a UI like: - An update has been found. Would you like to install it now? Yes/No - Click yes, update runs, final dialog says "Update complete, restart required". - No preview, no version numbers, no IU names or ids, etc. It may need just the license agreement page, but even that could be omitted if there were no licenses present in the metadata (if it's a locked down application with strictly controlled repos, a license agreement step may not be needed).
We have an example of this in org.eclipse.equinox.p2.examples.rcp.prestartupdate This example checks for updates on startup. The only "UI" per se is the progress indicator that says its checking for updates. If found, the updates are installed and the app is automatically restarted. So it just feels like part of the startup process. It sounds like the only additional thing needed for the use case described is to allow the user to confirm that they want to install the updates when found rather than automatically do it. In this use case, I'm not so sure there is really anything to formally support from a UI point of view, although we could provide a supported version of the code that checks for updates. See also http://wiki.eclipse.org/Equinox/p2/Adding_Self-Update_to_an_RCP_Application#Headless_Updating_on_Startup
I was the ascerbic presenter who rather rashly made these comments - but I am delighted to discover the addition of this 'bug'. I'll read through the link that Susan made and comment further anon.
I wonder if it would be useful to put together a template for the new plug-in wizard that would add something like this to the RCP Mail Template. (I have no idea of what is involved with that).
Well I got the example work, but i'm facing an issue. When under vista, I specified the -Dosgi.configuration.area=@user.home/Product/configuration. But with the p2util code, it downloaded the plugins but generating a new config.ini under installation directory/configuration/. When running, the RCP application will not pick up the newest plugins, as the bundles.info didn't update and point to the old plugins. Any idea of this?
(In reply to comment #5) > Well I got the example work, but i'm facing an issue. > When under vista, I specified the > -Dosgi.configuration.area=@user.home/Product/configuration. But with the p2util > code, it downloaded the plugins but generating a new config.ini under > installation directory/configuration/. When running, the RCP application will > not pick up the newest plugins, as the bundles.info didn't update and point to > the old plugins. Any idea of this? > I'm not sure what's going on here. Simon, do you know? (the P2Util class is just doing the garden variety stuff - building a profile change request, planning, executing the plan in the engine). This may be a separate bug (or perhaps an already known one?)
Let me make it clear. If using default configuration/p2 folders, i.e. under the installation folder, the p2util works all right. However if I specify a configuration/p2 folder via the -Dosgi.configuration.area=@user.home/Ruskin/configuration, then the org.eclipse.equinox.simpleconfigurator\bundles.info file will not be updated to the latest version. I read the code of p2, but didn't find anything at the moment.
Hmm... that's strange as it should work. In your product do you have org.eclipse.equinox.p2.reconciler.dropins started? That bundle does some initialization of the user configuration area and could be the problem.
I started following bundles in the Activator. getBundle("org.eclipse.equinox.util").start(Bundle.START_TRANSIENT); //$NON-NLS-1$ getBundle("org.eclipse.equinox.p2.exemplarysetup").start(Bundle.START_TRANSIENT); //$NON-NLS-1$ getBundle("org.eclipse.equinox.p2.reconciler.dropins").start(Bundle.START_TRANSIENT); //$NON-NLS-1$ getBundle("org.eclipse.equinox.frameworkadmin.equinox").start(Bundle.START_TRANSIENT); //$NON-NLS-1$ getBundle("org.eclipse.equinox.simpleconfigurator").start(Bundle.START_TRANSIENT); //$NON-NLS-1$ getBundle("org.eclipse.equinox.simpleconfigurator.manipulator").start(Bundle.START_TRANSIENT); //$NON-NLS-1$
Several thing have found. 1. LazyManipulator looks the code to save the bundles.info. But the p2util didn't init it, did it? 2. I tried to init it manually with following code. EclipseTouchpoint touchpoint = new EclipseTouchpoint(); touchpoint.initializePhase(null, profile,"test", parameters); 3. Get the LazyManipulator of the given profile via Manipulator manipulator = (Manipulator) parameters.get(EclipseTouchpoint.PARM_MANIPULATOR); 4. The manipulator.getLauncherData().getFwConfigLocation() return the file point to the installation file. Shall it be the @user.home/Product/configuration? 5. The FWConfigLocation is inited by the following code in the Util class of touchpoint.eclipse plugin. String config = profile.getProperty(IProfile.PROP_CONFIGURATION_FOLDER); if (config != null) return new File(config); return new File(getInstallFolder(profile), "configuration"); //$NON-NLS-1$ 6.The profile is accessed via the code in p2util final IProfile profile = profileRegistry .getProfile(IProfileRegistry.SELF); Looks property IProfile.PROP_CONFIGURATION_FOLDER of the profile didn't initialized to the correct path,i.e. @user.home/Product/configuration. Above is the thing I can find now. Can anyone provide any comments of what's wrong there? BTW it's a tough task to trace the code without the PDE debugging tools. Any idea of setting up a self-hosting environment to debug the code. Thanks.
*** Bug 290824 has been marked as a duplicate of this bug. ***
Thanks Susan for redirecting the conversation here. I had seen this entry earlier but it slipped my mind... Anyway, it would be great if an updater like this could be polished and made minimally configurable. In other words, I'd like to see a simple update mechanism, but not featureless. Again, I'm thinking about something like Sparkle as a good example. http://sparkle.andymatuschak.org/ So features that might be interesting would be: * Configurable ability to skip the install * Configurable ability to show license or not * Usability options such as "what's in this release". Not sure how this fits with p2. * Ability to specify an image to display in the wizard Others might have additional features they'd like to see, but this is my shortlist. So would it be possible to implement something like this in the 3.6 timeframe? Thanks! --- Patrick
(In reply to comment #12) > Thanks Susan for redirecting the conversation here. I had seen this entry > earlier but it slipped my mind... No worries. I noticed after duping your bug that it had votes, I wasn't trying to lose those. ;-) > > Anyway, it would be great if an updater like this could be polished and made > minimally configurable. In other words, I'd like to see a simple update > mechanism, but not featureless. Again, I'm thinking about something like > Sparkle as a good example. > > http://sparkle.andymatuschak.org/ I think the sparkle reference gave me an "a-ha" today. I have felt for some time that we have all the building blocks to give you what you want, we just aren't making it easy to configure the UI that way. Something like the headless update example with an optional available updates wizard. But the sparkle reference helps me realize that when some people say "simple RCP UI" a big part of it is the branding and pizazz. I think the main attraction with sparkle is that it lets the product be the product. You get the feature list/release notes/product branding in the update notification. You get the marketing words about why you want this cool update. Snazzy. Or at least as snazzy as the graphics and release notes that were created for the product. Contrast that to the SDK UI where we show the updates in a list, because we are supporting the generic "system composed of building blocks" scenario. Systems where the user installs add-ons, or is aware of maintenance patches, etc. Whether it's the SDK or some other RCP app, if the users have visibility into the composition of the system, then the update UI is more complex. It's also rather boring, because you lose the "personality" of a single branded app, and just get a boring list of updates a la windows security updates. Even worse, because we worry about the performance of multiple updates/multiple sites/etc. etc., we don't even retrieve the branding info for each update, so you don't even see a different icon for each one. In the RCP world, there is often only one thing that can ever be updated. If we treated the "only one thing to be updated" case specially, so that release notes or licenses, or custom graphics, etc. could be summarized in one page, then that could go a long way toward giving a sparkle-like experience. > > So features that might be interesting would be: > > * Configurable ability to skip the install > * Configurable ability to show license or not We already support this, it's just requires code to customize the UI. Andrew's suggestion in comment 4 might help (wizards to ask the questions as you pose them and generate the right code), although I sense that what people really want is some bundle they can add-on, maybe configure some options in a file and be done with it. > * Usability options such as "what's in this release". Not sure how this fits > with p2. > * Ability to specify an image to display in the wizard Here we are bitten by the genericity of p2 metadata. We don't presume you have features, or particular branding info, or anything else. (For example, see bug 252014 and all its duplicates). > > Others might have additional features they'd like to see, but this is my > shortlist. So would it be possible to implement something like this in the 3.6 > timeframe? Anything is possible. ;-) I think this could happen in the 3.6 timeframe if someone with an RCP perspective, such as yourself, would step up to help. Things like: 1 - help define how you'd rather express the UI configurability described in http://wiki.eclipse.org/Equinox/p2/Adding_Self-Update_to_an_RCP_Application#Configuring_the_p2_UI. ie, make a sample configuration file that defines the things you want to configure, such as install=false update=true license=false repositoriesAreVisible=false forceupdates=true, etc. etc..... Maybe that's what this bug should be focused on. I think most if not all of what you want can already be configured in code, it's just not simple to figure it out. This file could be read and the UI policy would be configured appropriately. In fact, making this work could be completely doable by someone outside of p2 (by supplying an alternate UI bundle along the lines of what I describe in the wiki) and I would be happy to answer any questions or make changes in the p2 UI policy or wherever else needed to support it. 2 - how is branding info to be defined by the RCP app developer and read by the UI? Does it belong in the metadata, or do we just need a way to look for and pre-download a branding bundle. If it belongs in the metadata it affects tooling workflows (PDE editors, export/publishing, etc.). Perhaps that effort could be done in bug 252014. With those two things defined, I think the only missing piece would be snazzing up the update wizard to show the branding info and special-casing the "only one thing to update" case so that you get a one-page update confirmation with everything you need. Note that I don't have a simple solution for making "Install New Software..." any simpler, but so far everyone seems to be talking about update, not an "add-ons" strategy.
(In reply to comment #13) Thanks for the detailed reply. I'd be happy to help with the requirements and it would be great if we could put this together for 3.6. I also hope some other developers will comment here to make sure we don't miss anything. I won't quote all of your comments on the difference between a "simple" update UI and the existing update manager, but I agree with all of them. I especially agree that a simple update manager should focus on updating products as opposed to assembling features. Based on my experience, this would make sense for most corporate and commercial RCP app developers. As for the details... > We already support this, it's just requires code to customize the UI. Andrew's > suggestion in comment 4 might help (wizards to ask the questions as you pose > them and generate the right code), although I sense that what people really > want is some bundle they can add-on, maybe configure some options in a file and > be done with it. It's great that most of the code to make this work already exists. What we need is to package the functionality and make it *really* easy to configure. I agree most developers would like to configure options in a file. Here's one suggested scenario: * Developer can add everything needed by adding a single feature to a product. Right now we can add org.eclipse.help to our feature to bring in help. Something like that would be great. * A way to specify a few simple configuration options. A simple approach would be to just use the plugin_customization.ini file. Again, this would mimic how we customize the help system. Or if we wanted to use a branding plugin, we could specify an update.ini just as we know specify an about.ini. > Anything is possible. ;-) I think this could happen in the 3.6 timeframe if > someone with an RCP perspective, such as yourself, would step up to help. > Things like: > 1 - help define how you'd rather express the UI configurability described in > http://wiki.eclipse.org/Equinox/p2/Adding_Self-> > > Update_to_an_RCP_Application#Configuring_the_p2_UI. > ie, make a sample configuration file that defines the things you want to > configure, such as > install=false > update=true > license=false > repositoriesAreVisible=false > forceupdates=true, etc. etc..... Here's a quick list roughly-based on the configuration pages for Sparkle: http://sparkle.andymatuschak.org/documentation/pmwiki.php/Documentation/Customization automaticallyCheckForUpdates automaticallyDownloadUpdates (forceupdates above?) showReleaseNotes showLicense releaseNotesUrl And some we would need: licenseUrl imageUrl repositoryUrl I'm not sure what repositoriesAreVisible would do. Would you display a list in the UI? If so, I'd say we should avoid this in the simple UI. > 2 - how is branding info to be defined by the RCP app developer and read by the > UI? Does it belong in the metadata, or do we just need a way to look for and > pre-download a branding bundle. If it belongs in the metadata it affects > tooling workflows (PDE editors, export/publishing, etc.). Perhaps that effort > could be done in bug 252014. My gut feeling is that branding plug-ins are kind of "old-school", but if this is the best way to get things done I have no problem with that. Conceptually, I think it makes more sense to associate all of the update configurations with a product somehow (like license is already), but we'd obviously need to make PDE changes to make that work. > Note that I don't have a simple solution for making "Install New Software..." > any simpler, but so far everyone seems to be talking about update, not an > "add-ons" strategy. Agreed. I say we focus on a pure product update story. I'm sure someone will say they want a simple way to install "add-ons" to their product, but I say we leave that for another day. So to sum things up, here are my questions: 1. Would it be possible to create a feature that provides everything an RCP developer needs to add the simple updater to a product? 2. Is it worthwhile exploring adding update configuration to a product definition, or should we focus on leveraging existing solutions (branding plugin or plugin_customization.ini)?
Thanks for the input, Patrick. Skipping down to your questions... > > 1. Would it be possible to create a feature that provides everything an RCP > developer needs to add the simple updater to a product? yep, I've opened bug 290973 for this and assigned to myself in M4. It turns out that this is mostly an exercise in exposing some new configuration preferences and mapping those to the existing UI Policy overrides. I see this starting out as an example and then as we get feedback, it could probably get promoted to being something "official." In fact it might solve another problem we have, which is how to expose UI API for configurability without tying ourselves down. See that bug for details. > > 2. Is it worthwhile exploring adding update configuration to a product > definition, or should we focus on leveraging existing solutions (branding > plugin or plugin_customization.ini)? I agree that the branding plug-in feels old school, not to mention there are technical issues with it: - p2 is designed to provision anything/everything, not just eclipse plug-ins. So it doesn't have a feature model and doesn't know squat about branding plugins at the metadata level. - I don't want to have a special feature based UI that knows what to do with those plug-ins because it can't be used generically. - Metadata retrieval needs to be simple/fast. I mentioned bug 252014 (branding icon in the metadata) as part of the solution, but I realize this isn't as important when we are just updating something we already have. The branding icon is really more useful when you're doing a firefox-style add-on approach, where you are showing lots of different things and want to distinguish them from each other. Instead, I think we could start by using existing metadata (the IU description URL) to retrieve info about an update. Then the only thing left to do is optimize the update wizard for the "only one thing to update" case. This is described in more detail in bug 290972. Those bugs have been marked as 3.6M4. This bug will remain open to collect further requirements, but my claim is by fixing the two detailed bugs you will be able to have what you want.
That all sounds great, Susan. Thanks! When the example is ready for testing I'll blog about it so we can get some good feedback from other developers. Thanks again, --- Patrick
Created attachment 149181 [details] Simple update flow 1
Created attachment 149182 [details] Simple update flow 2
Created attachment 149183 [details] Simple update flow 3
I was updating some software using Sparkle today and thought I'd capture screenshots of the process. The three shots illustrate what I think is the bare-bones desired flow for most RCP apps. I know there will be more to the wizard (licenses, etc.), but it would be great if a flow as simple as this was possible. --- Patrick
I think we are just about done on this issue. I've just updated the rcp.cloud example to show how the plugin_customization.ini file can drive the behavior of the update and install UI. There are just two remaining issues that prevent us from packaging this as a "bolt-on" feature that requires no coding vs. the current example. - bug 311475 would be needed to allow the product configurer to control whether branded update notification was used or the multiple update notifier. This would be new API so I can't do it for 3.6. - the rcp.cloud example still includes an install and an update handler. I've left it this way so that it can demonstrate all the possible ways to configure hte update UI. However, if we truly want a bolt-on, no-code approach, we could remove the install handler so that this is only a "self update" feature. A product configurer could also add the discovery feature if they want install. Marking this bug for 3.7. As soon as HEAD is open after 3.6, I will fix bug 311475 and make a self-update feature. In the meantime, the rcp.cloud example shows exactly what to do.
I just brewed together a very rough feature 'com.example.p2.simpleupdate' and a bundle 'com.example.p2.simpleupdate.utils' containing the P2Util code from the wiki and the Install/Update handlers from the cloud example. I had to disable progress monitoring for now for the auto update because it caused trouble for me (I suspect it might be because of the unsigned content warning dialog). This can be used to add update support to rcp applications instantly: - Get http://github.com/ralfebert/p2_autoupdate - Add org.eclipse.equinox.p2.user.ui and org.eclipse.core.net to the .target platform - Add the feature com.example.p2.simpleupdate to the product - Add p2.inf to the root of the plugin containing the .product to configure the software site URL, f.e. instructions.configure=\ addRepository(type:0,location:file${#58}///tmp/updates/);\ addRepository(type:1,location:file${#58}///tmp/updates/); - Call P2Util.checkForUpdates() in ApplicationWorkbenchAdvisor#preStartup to enable updates on startup - Add the commands org.eclipse.equinox.p2.examples.rcp.cloud.command.update and .install to the menu as needed. I'll try to polish this to something like a 'p2.rcp.support' bundle providing base classes for common update cases. Thanks to Susan for the example code & great advice
I just cleaned up the http://github.com/ralfebert/p2_autoupdate a bit more. Doing this, I stumbled upon this: - http://wiki.eclipse.org/Equinox/p2/Adding_Self-Update_to_an_RCP_Application recommends to use "ApplicationWorkbenchWindowAdvisor#postWindowOpen" to search of updates. Wouldn't this do an update search whenever a new workbench window is opened? I sticked to use WorkbenchAdvisor#preStartup and used ProgressMonitorDialog which seems to work so far. - In my recent try using the P2Util example code, I can see p2 accessing the content.jar in the repository on application startup and then returning with UpdateOperation.STATUS_NOTHING_TO_UPDATE even when there is an update. When I execute the UpdateHandler as in org.eclipse.equinox.p2.examples.rcp.cloud manually, I get the update shown and installed. So there seems to be a difference between how ProvisioningUI.getDefaultUI().getUpdateOperation() and new UpdateOperation(new ProvisioningSession(agent)) works (and imho there shouldn't be a difference in that regard). Any hints?
*** Bug 322505 has been marked as a duplicate of this bug. ***
I just moved the autoupdate code to org.eclipselabs and will continue to maintain this as far as needed for my RCP applications till this bug is fixed. http://code.google.com/a/eclipselabs.org/p/p2-rcpupdate/ http://github.com/ralfebert/org.eclipselabs.p2.rcpupdate This is mostly code from the wiki/rcp cloud example in 'drop-in' form. Currently it contains the Install/Update command, P2Utils.checkForUpdates() and a feature with dependencies to all the required p2 bundles.
I looked at Ralf's latest code and have also started looking at the best way to provide the update feature. But won't finish for M2. I don't think Ralf's approach is general because it includes "install" functionality. For the simplest of RCP apps, there is nothing additional to install and we wouldn't want to assume the app supports install. For those that do support install, there are existing p2 discovery and of course the MPC (eclipse marketplace client) that could be used. So the approach here is to focus solely on update. Another thing to work out is that I think the update picture depends also on whether there are other things to be installed in the RCP app. I can imagine two styles of update: 1 - the "forced update" scenario where the app checks for updates and updates itself before the user ever runs the app. 2 - the "check for updates" scenario where the user does the check, and could optionally also have the auto-update settings similar to the SDK. I think this mainly makes sense when the app is composed of features and the user wants to check for updates to the pieces. This has been part of the challenge of having the "out of the box" update capability - we need little pieces of functionality so that RCP developers can pick and choose the one that works for their case. If we go with choice #1 then Andrew's suggestion in comment #4 of having a PDE template that generates the right code is interesting. Because the hook to call the check for update has to go in the RCP app's prestartup code.
I'd prefer a solution that does nothing out of the box but only provides the parts needed to enhance apps with update functionality. Like a very high level API to p2 and a p2 UI. Integrating such existing pieces manually (like, adding one line of code or the menu contributions) gives a lot of flexibility for custom enhancements already. "Forced update on startup" (like web start), "update in background automatically" (with and without notification) and "easy installation of extensions" (like Firefox extensions) are the most common cases I have encountered so far. That's why I made the rcpupdate bundle passive, it only offers the Install and Update commands and the P2Util.checkForUpdates method (if a command contribution is already too invasive, these could be just an API or a handler base class as well). IMHO it wouldn't hurt to include an install command that can be included with an app but doesn't have to. I included it only because I like to demo the capability of installing additional features. I already thought about using the Discovery UI for this because it is a lot more suitable for apps facing the end user.
I'm glad to see this work going forward! Here are a few thoughts on an additional dimension to this problem. Congruent with the goal of a simple update UI is the need for an API enabling people to write all sorts of simple update UIs. The default simple update UI described here could use the simple update API for its implementation, thus becoming an exemplar for how others could use the API. I have a fair bit of experience (3+ years) working on the corporate side of this problem, so can lend my voice to this conversation going forward. Questions: * This seems like a separate (but related) bug to this one. * Does anyone know if such a bug already exists? I don't see anything linked? Comment: * Part of the J.P.Morgan code contribution back at EclipseCon is a working implementation of this from a corporate point of view. It's currently built on top of Update Manager, but we're interested in migrating it to P2. We can take up that conversation in the other bug (when it's identified/created/linked to this one). Current installer API code is available from your friendly E4 Git Repo: http://git.eclipse.org/c/e4/org.eclipse.e4.installer.git/ http://git.eclipse.org/c/e4/org.eclipse.e4.utils.git/
(In reply to comment #26) > I don't think Ralf's approach is general because it includes "install" > functionality. For the simplest of RCP apps, there is nothing additional to > install and we wouldn't want to assume the app supports install. > > For those that do support install, there are existing p2 discovery and of > course the MPC (eclipse marketplace client) that could be used. > > So the approach here is to focus solely on update. Hi Susan, Maybe I'm missing something here, but in the general cases that I've seen, installation of new Features is just a subset of updating and a natural part of moving an application from one major rev to another major rev. Have I missed something? Or to say the same thing in a different way, we view the simplest case as, "Make the features/versions in the running platform exactly match the features/versions in some P2 repo." To synchronize with a remote, in other words. From there, I've seen multiple remote P2 repos added in either or a mixture of the following configurations: - Multiple repos that exactly mirror each other for redundancy/failover in case one goes down. - Repos A contains the base platform, Repos B contains one set of functionality, Repos C contains additional features not in either A nor B, etc. ie: Break down the sites along functional lines to make upgrades of various parts easy.
these bugs will be my holiday projects...
(In reply to comment #29) > Hi Susan, > > Maybe I'm missing something here, but in the general cases that I've seen, > installation of new Features is just a subset of updating and a natural part of > moving an application from one major rev to another major rev. > > Have I missed something? I think so. Simple RCP apps don't expose any kind of feature model to the user. The app is just the app. So there is no install at all. Even if there are features being updated under the covers, the user just sees "upgrade "CoolApp" from 1.0 to 2.0, either by choice or in some cases, forced. Other RCP folks have said they want a "bolt-on feature" that adds update capability without writing any code. > > Or to say the same thing in a different way, we view the simplest case as, > "Make the features/versions in the running platform exactly match the > features/versions in some P2 repo." To synchronize with a remote, in other > words. I agree that to users who are aware of a feature model and permitted to install new ones, install is just part of the same process. As you and Ralf mention, in more complex scenarios, it's okay to write a couple lines of code and pick which install (native p2, p2 discovery, EMP client, etc.) should be used. > From there, I've seen multiple remote P2 repos added in either or a mixture of > the following configurations: > > - Multiple repos that exactly mirror each other for redundancy/failover in case > one goes down. > > - Repos A contains the base platform, Repos B contains one set of > functionality, Repos C contains additional features not in either A nor B, etc. > ie: Break down the sites along functional lines to make upgrades of various > parts easy. Yep, this all makes sense, but this bug is really expressing the requirement of RCP guys who just want to "update my app" no pieces and parts.
(In reply to comment #31) > Yep, this all makes sense, but this bug is really expressing the requirement of > RCP guys who just want to "update my app" no pieces and parts. Cool. Then you and I are talking about the same thing, just from different perspectives: You from the user's perspective, me from the developer's perspective. In our applications, the user only knows that the app updated itself because they saw the progress meter say that it did. If they're really savvy, they might realize that it restarted. :) They don't have any choice in what gets updated or what features are available to them. Sometimes the Features available to them are determined from their login credentials (there's a recent thread about this in P2-dev). All of the things I wrote about install versus update, multiple update sites, etc., are for the developer--so that they can create a scalable, maintainable solution. We've been spiking solutions around this space; if you're interested we might want to collaborate so we can cross-pollinate ideas and so we don't duplicate work. Our original Update Manager-based implementation is at: http://git.eclipse.org/c/e4/org.eclipse.e4.installer.git/ This code is our second generation implementation and has run in production for over a year and a half for both small and large investment banking applications--all of which implement no-touch automatic update during startup. Our intent has been to throw all this code away but the API and migrate it to P2. We feel that the API has proven itself to be useful for those who want an automated, zero-touch update for their RCP applications. Probably with minimal change it's also good for those who want to present a list of updates and ask the user for a Yes/No confirmation as well. So if you're interested, we'd love to collaborate and bring it forward. If anyone in the community sees deficiencies, we'd love to receive this feedback as well. For easy access, API is currently defined in the following two classes: http://git.eclipse.org/c/e4/org.eclipse.e4.installer.git/tree/bundles/org.eclipse.e4.enterprise.installer/src/org/eclipse/e4/enterprise/installer/BundleUpdater.java http://git.eclipse.org/c/e4/org.eclipse.e4.installer.git/tree/bundles/org.eclipse.e4.enterprise.installer.ui.swt/src/org/eclipse/e4/enterprise/installer/ui/swt/BundleUpdaterHelper.java I'd love your thoughts/feedback.
I'm starting a spike on this. Susan, are you working on this? Would you like to collaborate?
(In reply to comment #33) > I'm starting a spike on this. Susan, are you working on this? Would you like > to collaborate? I'm not looking to create any new API, and honestly most of my focus on this was completed in 3.6. The operations API, branded update wizard, extended examples, etc. were aimed at this problem. (See dependent bugs and their dependent bugs, etc.) I still need to release my changes for bug 311475, but that was all I had planned to do. This leaves all the pices for the "sparkle-like" experience Patrick wanted. The rcp.cloud example also shows how to use the plugin_customization.ini file to drive all the settings of the update UI. The remaining question in my mind was whether we needed/wanted a bolt-on feature so that update could be added without any code. Ralf suggested (in comment 27) that instead we package up all the useful bits in a supported bundle (rather than some of it being in examples) so that RCP developers could decide which bits to use. If you are looking to bring new API into the mix, I would suggest looking at the operations API and examples that already exist and proposing how this fits in. I am happy to comment on the work, but don't have time to collaborate any more than that. I'm also not a consumer of this API, so I think you need feedback from RCP developers to tell you what is missing from the current API (folks like Ralf Ebert, Patrick Paulin, Miles Parker, etc...who have been very active in the existing bugs).
Assigning to Dean, as he is going to start looking after some p2 UI stuff. I just released the API for bug 311475. Here's what I think needs to happen at this point. - Someone (Dean?) should go through the steps of generating a v 1.0 of an RCP app, and then generating an update for it, for which a branded upgrade notification is used. I have lost track of where our tooling is on making it easy for an RCP developer to define the update descriptor location URL. (I had to hand-hack the metadata last year for the eclipse con demo). We need to open publisher/PDE bugs if it's not easy to specify the URL for the branded notifier. - RCP cloud example now has the new code, but we need the update repo itself to be added to CVS so that someone can go through all the steps by example - I like Andrew's comment 4 idea...we add code to RCP Mail to generate the update code so that people can follow it - We move the preference reading/CloudPolicy example code to a supported "update tooling" bundle. In the absence of input from the community, I don't think we know enough at this point to say that we know how a "bolt-on" feature should perform update (automatically at startup, at user request, etc. etc.)
I'd like to do to things in this reply: 1) Clarify exactly what we're proposing. 2) Ask the community how people would like to structure the bugs/work. == What we're proposing == (In reply to comment #34) > If you are looking to bring new API into the mix, I would suggest looking at > the operations API and examples that already exist and proposing how this fits > in. That's exactly what we've done: Looked at the operations API and abstracted on top of it. We've been focused on one very common use-case (and a few logical extensions): an application that automatically updates itself with minimal or zero user intervention. e.g.: http://www.modumind.com/2009/09/29/a-simple-update-manager-for-eclipse-rcp-applications/ We've got that use-case down to three lines of code, including the "if" test to see if the application needs restarting and actually restarting the workbench. The update itself is one line of code. But we don't stop there. Commercial service-oriented applications (internal corporate or public commercial) often also want to turn a particular user's functionality on or off based on a user's login credentials--either as a means for implementing role-based security or as a way to induce a customer to pay more money for more features. :) In this scenario, the update is still one line of code. We feel that for a *lot* of people, this is exactly the right level of abstraction, and would be interested in feedback from the community. We don't mean for this in any way to detract from the operations API. The operations API has the effect of making our code a *lot* more readable, and some use-cases just aren't covered by our API, making the operations API still necessary. I'm happy to open a separate bug for this, but was hoping that the simplified update UI could be layered on top of a possibly-extended version of what we've done. For example, the use-case Patrick Paulin blogged is supported directly by our API. == Structuring the work == Okay, so I hope that's clear. The question now is: Should this work be kept with the work on the simplified update UI, in the same bug? The main reason I can think of for doing this is: - Eclipse is all about creating frameworks with exemplary tool implementations on top. In my view, what I'm proposing is a (small) framework. The simplified UI is the exemplary tool on top. - In my view, it makes sense to keep the framework together with the exemplary tool that uses it unless and until the work grows to a scope that it makes sense to split it up. In other words, don't prematurely optimize the organization. Now it's the community's turn. :) I've said what I think is a good way forward; I'm happy to receive feedback, thoughts, and hopefully to converge on an consensus.
It's been a while since there was any news on this one... was wondering if there's a chance this'll make it for Indigo? I got the impression there'd been a lot of work put in already and it was near the final hurdle?
(In reply to comment #37) > It's been a while since there was any news on this one... was wondering if > there's a chance this'll make it for Indigo? I got the impression there'd been > a lot of work put in already and it was near the final hurdle? There's been work on API to support this but AFAIK, not UI. Search for SynchronizeOperation, bug #337016 for details.
(In reply to comment #37) > It's been a while since there was any news on this one... was wondering if > there's a chance this'll make it for Indigo? I got the impression there'd been > a lot of work put in already and it was near the final hurdle? Most of this got finished late in 3.6, (see Ralf Ebert's blog post http://www.ralfebert.de/blog/eclipsercp/p2_updates_tutorial_36/). The branded update wizard was internal in 3.6, we added API in 3.7 so that it's officially supported. If you follow the dependent bug links you'll see information on these various improvements. What we did not do (and the reason this bug is not closed) is tie everything up in a nice example package and update the wiki accordingly. We considered doing an RCP mail template wizard to demonstrate it, and just did not have the time. There was also various discussion about how to simplify the amount of core code needed to do an update, and doing updates automatically without user intervention. This is the work Dave is referring to.
Help is wanted here.
Been reading through the reams of associated bugs and have finally managed to look in the Cloud Update example... Just one question - how do you provide the branding URL to the UpdateSingleIUWizard? I thought it'd be via the p2.inf but I came across bug 354260 so looks like that's not ready yet. There's an 'updatenotification.png' image in the example which also appears in the presentation (http://www.slideshare.net/susanfmccourt/simplifying-rcp-update-and-install) on page 16. There's some metadata shown on p15: <unit id="org.eclipse.equinox.p2.examples.rcp.cloud.product" version="2.0.0.z201003162033"> <update id="org.eclipse.equinox.p2.examples.rcp.cloud.product" description="This update contains Mylyn Discovery!" range="0.0.0" severity="0" uri="file:/C:/_projects/eclipsecon2010/updatenotification.png"/> Is this just manually edited into the newer repo's artifacts.xml/jar?
(In reply to comment #41) > Is this just manually edited into the newer repo's artifacts.xml/jar? Unfortunately, yes. I don't think the tooling support for this was ever added.
Created attachment 207176 [details] AutomaticUpdatesPopup popup will raise the default-style dialog I've finally found the time to implement this - looks great! However, I've come across an inconsistency that arises from the AutomaticUpdatesPopup notification that is shown when updates are available. Clicking the popup will raise the default-style dialog which isn't consistent with the SingleIUWizard that's raised from the "check for updates" menu. See attached image. Currently the only workaround would be to check out the code and create a modified plugin, I believe? I think users of the SingleIUWizard would want the AutomaticUpdatesPopup to show it also, no?
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. -- The automated Eclipse Genie.
