|Lately I became familiar with the discovery code and it does not seem to cover his needs which are much more like a synchronization, where the catalog is much more to drive addtions.|
On 2011-02-08, at 3:59 PM, Steffen Pingel wrote:
not sure if you have already looked at the API in p2 Discovery:
DiscoveryUi.install(List<CatalogItem> descriptors, IRunnableContext context);
CatalogItem is a simple class that describes properties where to find IUs and which IUs to install.
We have been discussing generalizing this API further to provide Mylyn users with a simple way to update Mylyn outside of release train cycles. If you start working on this as part of e4 please CC me on the bug and if you are interested we could consider providing API in p2 Discovery.
On Tue, Feb 8, 2011 at 12:25 PM, David Orme <djo@xxxxxxxxxxxxxxxxxxxxxxxxx>
On Tue, Feb 8, 2011 at 12:41 PM, Henrik Lindberg <henrik.lindberg@xxxxxxxxxxxxxx>
kudos to the initiative!
I think there needs to be something that describes a policy for how the "install" should be performed. I think the biggest problem is designing these to capture the typical use cases. I am thinking of :
The two extremes are
- just give me bug fixes (conservative, change as little as possible)
- give me the latest of everything including platform
There is probably at least one intermediate level where user wants to stay on same platform (e.g. 3.6) but then wants the latest of everything else.
It is not always possible to control this by presenting a limited set of repositories.
Right. If I wanted to design an RCP app for these use-cases, I would use the second API and explicitly pass the IUs I want to update into the installer.
If you wanted to be more automatic than that, how would you want to represent this? Pass a p2ql query into the installer that would be used to select what you want?
p2-dev mailing list
Senior Developer, http://tasktop.com
p2-dev mailing list