[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [p2-dev] Proposal: Simplified installer/updater.
|
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
<ereiswich@xxxxxxxxxxxxxx> 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
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
