Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Proposal: Simplified installer/updater.

Inline.

On Tue, Feb 8, 2011 at 2:53 PM, Pascal Rapicault <pascal@xxxxxxxxxxxx> 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


Back to the top