Think I got my second question answered :) The second install, I would call it "makeItSo" :)
The question I still have is, why would not those be cast in terms of ProfileChangeOperation (in the sense, inherit from there), maybe with a additional helpers? On 2011-02-07, at 5:04 PM, David Orme wrote: > 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
