Two (probably quick) questions: 1) Just noticed that the P2 API for getting an artifact or metadata repo takes a URI, not a URL. So I believe the API should be updated to:
public InstallStatus install(Set<*URI*> p2Sites) throws InstallError public InstallStatus install(Set<*URI*> p2Sites, Set<IVersionedId> featuresRequested) throws InstallError 2) For our purposes, is it okay to use the same location for the metadata repo and the artifact repo? Or should we also have methods that allow to separate these? *i.e.: Does anybody on this list have real P2 repos in production which separate the artifact repo location from the metadata repo location?* (ie: we can always evolve the API this direction, but I'm currently unconvinced that the first implementation needs this. Please feel free to try to convince me. :-) ) Thanks in advance, Dave On Mon, Feb 7, 2011 at 4:04 PM, David Orme <[email protected]>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
