Inline.
On Tue, Feb 8, 2011 at 2:53 PM, Pascal Rapicault <[email protected]>wrote:
> Comments embedded.
>
> On 2011-02-07, at 5:04 PM, David Orme wrote:
>
> <snip/>
> 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.
>
> Given the description, I would rather call that "synchronizeWith" because
> using the term install would confuse the meaning of installing. In this case
> you are installing everything contained in the repository, not the
> repository itself.
>
Agreed; that's a better name.
>
>
> 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.
>
> How does it differ from the InstallOperation()?
>
The implementation first performs an UpdateOperation, then an
InstallOperation.
It's still really synchronizeWith(), but now with a constrained set of
IVersionedIds.
> *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).
>
> Any objection in putting it in the p2 incubator?
>
Personally, no, as long as we can use Git to access the repo (firewall
concerns).
Practically, (for the moment) it's got to be E4 that's where I have
permission to put the code. To change that requires talking with lawyers.
:-{
But I'll make it a priority to get that changed if you like.
Dave
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
