Hi Pascal,
this is a good start. There could be one problem with the factory:
> ref = Activator.getContext().getServiceReferences(IProvisioningAgent.class,
> '(' + IProvisioningAgent.SERVICE_CURRENT + '=' + Boolean.TRUE.toString() +
> ')');
Due to the OSGi concurrency this call can cause a NPE.
The factory could look like:
> InstallOperation operation = new
> SimpleCaseFactory().createInstallOperation(versionedIdList, repoURIList,
> monitor);
> UpdateOperation operation = new
> SimpleCaseFactory().createUpdateOperation(versionedIdList, repoURIList,
> monitor);
> UninstallOperation operation = new
> SimpleCaseFactory().createUninstallOperation(versionedIdList, monitor);
> List<IVersionedId> features = new
> SimpleCaseFactory().getInstalledFeatures(monitor);
Eugen
Am 11.02.2011 um 04:36 schrieb Pascal Rapicault:
> I have created the following helper class (see attachment). It is a factory
> that hides much of the boiler plate you showed.
> I have not run the code itself but it would be used this way. I find it to be
> a good compromise since it allows one to create an operation quickly and use
> it, or tweak it some more and then use it. What do you think?
>
> InstallOperation operation = new
> SimpleCaseFactory().createOperation(versionedIdList, repoURIList, monitor)
> result = operation.resolveModal(monitor);
>
> if (result.isOK()) {
> final ProvisioningJob installJob =
> operation.getProvisioningJob(monitor);
> result = installJob.runModal(monitor);
> }
> <SimpleCaseFactory.java>
>
> On 2011-02-10, at 9:55 AM, Eugen Reiswich wrote:
>
>> I understand that you P2 developers have to deal with many different and
>> probably sometimes contrary requirements. And there is definitely no way to
>> meet all needs with one common API. But I just remember the legacy Eclipse
>> UpdateManager which has done his job for years, thus obviously covering a
>> lot of common scenarios. The API was very simple and easy to use:
>>
>> UpdateCommand(String featureId, String version, String verifyOnly)
>> InstallCommand(String featureId, String version, String fromSite, String
>> toSite, String verifyOnly)
>> etc.
>>
>> I am just of the opinion that if P2 could provide a comparable API this
>> would make the life of many developers much easier and encourage developers
>> to use P2. And in case this API does not meet a developers needs, he or she
>> can still fall back on the P2 concepts:
>>
>>
>> final IProgressMonitor monitor = new NullProgressMonitor();
>> ProvisioningSession session = new ProvisioningSession(agent);
>> ProvisioningContext context = new ProvisioningContext(agent);
>>
>> updateRepositories(context, updatedRepoLocation);
>>
>> Collection<IInstallableUnit> unitsToInstall = new
>> ArrayList<IInstallableUnit>();
>>
>> for (IVersionedId versionedId : featureIds) {
>> Version version = Version.create(versionedId.getVersion());
>> IQuery<IInstallableUnit> installableUnits =
>> QueryUtil.createIUQuery(versionedId.getId(), version);
>> IQueryResult<IInstallableUnit> ius =
>> context.getMetadata(monitor).query(installableUnits, monitor);
>>
>> unitsToInstall.addAll(ius.toSet());
>> }
>>
>> final InstallOperation operation = new InstallOperation(session,
>> unitsToInstall);
>> operation.setProvisioningContext(context);
>>
>> result = operation.resolveModal(monitor);
>>
>> if (result.isOK()) {
>> final ProvisioningJob installJob =
>> operation.getProvisioningJob(monitor);
>> result = installJob.runModal(monitor);
>> }
>>
>> Eugen
>>
>>
>> Am 10.02.2011 um 05:25 schrieb Pascal Rapicault:
>>
>>> To me the danger of adding yet another abstraction ends up being an issue
>>> of having more layers to keep aligned as things evolve in one or the other,
>>> and thus more code and API surface. To be clear, the actual functionality
>>> you want to add is very useful but the API you are using to represent it is
>>> limiting and goes against a lot of efforts that have been going on to run
>>> multiple instances of p2 in the same system. Therefore if we just go with
>>> the API as you propose it, next thing you will know, you will have request
>>> to offer the possibility to specify an agent, tweak the restart policy,
>>> then a this or a that... and we will end up with something that will be
>>> almost like, but not exactly like PCO which will result in even more
>>> confusion. And on top of that you will have to add the methods for cases
>>> like those from Eugen (true usecase as well there).
>>>
>>> In the end I think we are trying to resolve two problems in one shot:
>>> 1) Lack of functionality around sync'ing a p2 instance with a remote
>>> repository.
>>> 2) Ease of use of the API
>>>
>>> My proposal is to treat those separately:
>>> - The missing functionality is interesting and should be added. If I was to
>>> add that functionality just by itself, I would likely add it directly to
>>> the operations because this is where we expose these sorts of high level
>>> functionalities, and I would try to add the same support in the
>>> director.app.
>>> This would be a subclass of the InstallOperation that overrides the
>>> getProfileChangeRequest() to create a request that describes the expected
>>> final state.
>>>
>>> - Then separately if someone was coming to talk about simplify the p2 API,
>>> I would first try to understand how far from the Operation API is the
>>> desired state and then see how we can pave the way. For example: What about
>>> providing a factory that returned an API where you had pretty much just one
>>> or two method calls to do? like new InstallOperation(URI[] repos,
>>> IVersionedId[]).getProvisioningJob().schedule?
>>> For example, in one case there is an API to list the features to install,
>>> how would the caller of this new API get the elements to fill the list? I
>>> mean does he/she has to query the list of IUs from a repo?
>>>
>>>
>>> On 2011-02-09, at 10:35 PM, David Orme wrote:
>>>
>>>> Hi Susan,
>>>>
>>>> I'm open to considering making this code part of the operations API, but
>>>> right now have a hard time imagining it there.
>>>>
>>>> Right now, the code is basically a 300 line script (that happens to be
>>>> written in Java) that utilizes several Operations to get its job done. In
>>>> other words, it really feels to me like a layer of abstraction above
>>>> operations.
>>>>
>>>> I've looked at the code that Eugen and Scott wrote and their API is almost
>>>> exactly what we've proposed as well.
>>>>
>>>> Actually, theirs is probably a more proper abstraction layer on top of
>>>> Operations and ours takes their idea one step further and really
>>>> specifically enables some RCP use-cases. (Theirs is designed as a
>>>> remote-management API for Equinox-based server containers.)
>>>>
>>>> So my own thinking is that we should try to take into account our own
>>>> use-cases and theirs as much as possible.
>>>>
>>>> And to my thinking, that doesn't necessarily make sense as part of the
>>>> Operations API.
>>>>
>>>> However, I welcome attempts to convince me otherwise. :-) A code snippet
>>>> showing how one would use one of our APIs, but reimplemented using
>>>> Operations, to update an RCP application might be helpful to make it
>>>> easier to imagine what you're considering.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Dave Orme
>>>>
>>>>
>>>> On Wed, Feb 9, 2011 at 11:10 AM, Susan Franklin McCourt
>>>> <[email protected]> wrote:
>>>> I agree that being part of the ProfileChangeOperation hierarchy would be a
>>>> good thing. Whereas InstallOperation will only do the updates forced by
>>>> requirements, you are talking about wanting to do other selected updates.
>>>> I think this can easily be accommodated in that hierarchy.
>>>>
>>>> As far as simplifying the number of concepts to use. It strikes me that
>>>> most of what you are talking about is simplified constructors that create
>>>> the operation by assuming an RCP setup (getting the agent and services
>>>> from the running profile.) So you could add those constructors for
>>>> simplicity and still retain the operation concept.
>>>>
>>>> This would have several advantages in my opinion:
>>>> - a remote administrator would surely want to use this concept to update a
>>>> system other than "self" profile. The operation would let them do this,
>>>> otherwise you have to start adding those very same concepts into this new
>>>> API.
>>>> - operations can feed into the UI, so if a more advanced use case required
>>>> the user confirming which updates/installs were needed, you could just
>>>> open a wizard (or make minimal change to existing wizards).
>>>>
>>>> I realize the purpose of your proposal is to get away from the
>>>> variables/concepts that pollute the RCP mindset, but my experience is that
>>>> someone will say, "it's just like your simple API but I want to pass an
>>>> agent in." or whatever. The operation hierarchy's purpose was to capture
>>>> the "80/20" use cases and I agree that the "synch profile with a
>>>> controlled repo" is one that is definitely needed...
>>>> I like the idea of SynchronizeProfileOperation or something like that.
>>>>
>>>> susan
>>>>
>>>> <graycol.gif>David Orme ---02/09/2011 07:23:18 AM---On Tue, Feb 8, 2011 at
>>>> 3:04 PM, Pascal Rapicault <[email protected]>wrote: > Think I got my
>>>> second
>>>>
>>>> From: David Orme <[email protected]>
>>>> To: P2 developer discussions <[email protected]>
>>>> Date: 02/09/2011 07:23 AM
>>>> Subject: Re: [p2-dev] Proposal: Simplified installer/updater.
>>>> Sent by: [email protected]
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Feb 8, 2011 at 3:04 PM, Pascal Rapicault <[email protected]>
>>>> wrote:
>>>> Think I got my second question answered :)
>>>> The second install, I would call it "makeItSo" :)
>>>>
>>>> :-)
>>>>
>>>> The question I still have is, why would not those be cast in terms of
>>>> ProfileChangeOperation (in the sense, inherit from there), maybe with a
>>>> additional helpers?
>>>>
>>>> Because what we actually do is an UpdateOperation followed by an
>>>> InstallOperation. Our testing showed that this is what we needed to
>>>> perform a full synchronization.
>>>>
>>>> But if inheriting from PCO is a better choice, we could consider that.
>>>>
>>>> A question of my own:
>>>>
>>>> I don't think we've tested yet how to make sure that a Feature that is no
>>>> longer used gets removed from the running platform.
>>>>
>>>> In our first API, if a Feature or Bundle is removed from all of the
>>>> available repositories (and they are all reachable on the network), then
>>>> it should be removed from the running platform as well.
>>>>
>>>> In our second API, the collection of IVersionedIds should completely
>>>> define the provisioned platform for the user.
>>>>
>>>> Do we need to do something special to disable all Features not referenced
>>>> by one of those IVersionedIds (either in the set of P2 repos, or in the
>>>> parameter list)?
>>>>
>>>>
>>>> Dave
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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
