Hi,
kudos to the initiative!
I think there needs to be something that describes a policy for how
the "install" should be performed. I think the biggest problem is
designing these to capture the typical use cases. I am thinking of :
The two extremes are
- just give me bug fixes (conservative, change as little as possible)
- give me the latest of everything including platform
There is probably at least one intermediate level where user wants to
stay on same platform (e.g. 3.6) but then wants the latest of
everything else.
It is not always possible to control this by presenting a limited set
of repositories.
API wise, the described operations are not so much an "install" (which
to me sound more like "install something new") - looks more like an
"update" or "sync".
Just my 2c...
Henrik Lindberg
[email protected]
On Feb 7, 2011, at 11: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
