On 2011-02-11, at 9:33 AM, Eugen Reiswich wrote:
> Hi Pascal,
>
> this is a good start. There could be one problem with the factory:
Do you really think this would be sufficient or do you think it is
still too complex since they still have to call the jobs?
In order to continue the discussion I have opened bug 337016
>> 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
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
