Thanks! As always, assistance is appreciated.
Dave On Tue, Feb 8, 2011 at 3:14 AM, Eugen Reiswich <[email protected]>wrote: > Hi David, > > I absolutely agree with you and would welcome such an API! We use even in > 90% P2 for simple install, update and uninstall operations and thus would > like to use P2 rather as a black box. Currently we developers are concerned > with concepts like ProvisioningAgents, ProvisioningSessions, > ProvisioningContext, IQueryables and IQueryResults, InstallOperations etc. > There is a steep learning curve yet if developer want to use P2. In my > opinion P2 is a very big step forward compared to the UpdateManager but at > the same time it is very difficult to handle. To be honest we try to get P2 > working now for over two years, followed all the API changes but P2 is very > resistant :) > > Regards, > Eugen > > > Am 07.02.2011 um 23:04 schrieb David Orme: > > P2 team, > > *Overview* > > We have been proposing an additional layer on top of P2 to take care of 80% > of the auto-update use-cases really simply. The purpose of this message is > to run our proposed API past the community and make sure we're not doing > anything silly or stupid as well as to hopefully elicit constructive > feedback about this proposal. > > *Proposal* > > 1) public InstallStatus install(Set<URL> p2Sites) throws InstallError > > The purpose of this API is simply to synchronize the running platform with > the union of the IUs available on p2Sites. New stuff is installed; > out-of-date IUs are upgraded; IUs that no longer exist on any site are > removed from the local configuration. > > The InstallStatus return value is an IStatus. It (a) tells the client if > it needs to restart, and (b) encapsulates state that you might want to log > for diagnostic purposes. > > 2) public InstallStatus install(Set<URL> p2Sites, Set<IVersionedId> > featuresRequested) throws InstallError > > Sometimes you want to only make a certain set of Features available to the > user, based on their login credentials or if they've given you money, for > example. This API presumes that you've done whatever you need to determine > what IUs/Features you need, and it installs just those IUs/Features. All > other Features are disabled in the current profile. > > *Conclusion* > > Having these two APIs would handle all of the self-updating RCP > applications we have seen at my client and probably most of them out there. > This seems like a lot of expressive value for RCP (and possibly server-side > OSGi) clients. > > Unless someone objects, we would like to go ahead and implement these (and > incubate the work in the E4 repo). > > *Questions* > > Does anyone see any issues with defining API this way? For example, is it > okay for P2 to have a dependency on core.runtime (IStatus)? > > Any other thoughts/feedback? > > > Regards, > > Dave Orme > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > > > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > >
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
