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
>>> [email protected]
>>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>>
>> _______________________________________________
>> 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
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
