Eugen, I think it's totally cool that you (plural) and we have independently evolved nearly the same identical API. It looks like you might have some nice ideas/code of your own to contribute to this.
Dave On Wed, Feb 9, 2011 at 2:46 AM, Eugen Reiswich <[email protected]>wrote: > Hi Pascal, > > you are right, we try to use P2 for quite complex stuff, but when I look at > our API we put on top of P2, it is pretty simple: > public IVersionedId[] getInstalledFeatures(); > > public IStatus installFeatures(IVersionedId[] featureIds, URI[] > repoLocations); > > public IStatus updateFeatures(IVersionedId[] versionIds, URI[] > repoLocations); > > public IStatus uninstallFeatures(IVersionedId[] featureId); > > To get us so far, we had several sessions over a number of months with RCP > experts, emails with you and Scott Lewis from the ECF team. This API has > served us very well for the last months and covered 90% of things we wanted > to do with P2. The things we do with P2 are just amazing, but if things are > to complex, developers won't give it even a chance. > > Eugen > > > Am 08.02.2011 um 22:16 schrieb Pascal Rapicault: > > Hi Eugen, > > What would make it easier to use p2? More doc? More examples? Which API > would you simplify / how? > IIRC, what you are trying to do with p2 is not necessarily the "simplest" > thing (trying to remotely manage eclipses and show the content of their > profile. etc?), and I'm not sure that David's API would benefit you. > I can see how David's new API make things "easier" but again it only deal > with a very specific subset of the problem that does not fit everybody. For > example you would certainly not want to use this API against the Helios > repository, since it assumes the repository content is very controlled. > > PaScaL > > On 2011-02-08, at 4:14 AM, Eugen Reiswich 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 > > > > _______________________________________________ > 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
