On 2011-02-09, at 10:20 AM, David Orme wrote:
On Tue, Feb 8, 2011 at 3:04 PM, Pascal Rapicault <pascal@xxxxxxxxxxxx> 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.
It is honestly a direction that I would be more comfortable with because as Susan explained in another email, we would eventually be forced to open up the "tight" API to address the cases of those that are not modifying the running instance or there would be questions as to why it is in one layer and not another. So as a starting point, let's build around PCO and then add helper constructors or factories to help encapsulate of the "boring" objects :)
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)?
p2 will take care of removing anything that is not necessary. You don't have to worry about anything in that space. e.g. A -> B -> C and D -> C, if A gets removed, then B will get removed.
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
|
