| Re: [equinox-dev] [prov] p2 for starters |
Hi, Helmut.
I work on the p2 UI, so I can answer some of the UI questions and will defer to the core guys to answer the rest..
>- Is p2 allowing nested groups like these:
<snip>
>- Can you suggest a strategy on how to best filter a repos content, both
>based on users choices and entitlement? Is there a filter layer we can
>put on top of a repository or can we use special queries to achieve
>this? This one revolves around reducing the available groups/categories
>in the UI from the massive amount of available ones, also the user
>should not see any IUs (s)he won't be allowed to use later on...
There's not really a canned taxonomy for how to traverse a tree of IU's. IU's can refer to each other through their required capabilities, or for that matter using properties that you define. Groups happen to be a property that we define for filtering, but you could define your own.
We traverse a repo in a particular way in the admin UI, and a different, (yet similar way) in the SDK Update and Install group. The model elements are set up so that you can define this taxonomy in terms of queries. See the classes IQueryProvider and its implementors. You can traverse the "tree" of repos using queries such as AVAILABLE_IUS, INSTALLED_IUS, etc. That way any app can have its own filtering or hierarchy. The UI components such as the UpdateAndInstallGroup, and some of the actions, etc. are passed a query provider by the caller so that the particular tree can be built. This was designed so that the queries can be optimized at the server if need be, rather than relying on UI-side technology like viewer filters to accomplish this.
That said, there are probably some built-in assumptions that have crept into the code, so if you were to try this out, it would help prove that what I say is true. Note that all of our API is provisional for 3.4, so we expect some iteration as clients adopt, and I'd love to see someone try to build a completely different view of the world using this mechanism - that's why it's there.
>- How can we best listen to the installation process, the job framework
>seems not to allow us to retrieve the "percent complete" of an
>installation? This question originates from looking at our old installer
>that would send us strings like these: "Installation 5% complete:
>Currently installing eclipse/plugins/com.windriver.ide_3.0.0.jar", can
>we hope to get the same amount of progress information from p2 and the
>jobs framework?
We use the jobs framework and IProgressMonitor. The default progress reporting for jobs shows an overall percent complete and assigns sub monitors for reporting of subtasks such as downloads. The IProgressService framework allows you to plug in your own way of showing this progress. Right now we use the workbench progress reporting, so that as a download occurs, you see progress in the workbench status icon and can open the progress view to see the progress of the running jobs. In the future we may extend the standard progress reporting so that progress could be shown in-line in the install dialog, but probably won't get to this for 3.4.
I'll defer to the core guys for the rest, things are changing fast around here and I'm afraid I might give you old/incorrect info...
hope this helps...
susan
"Haigermoser, Helmut" <Helmut.Haigermoser@xxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx 03/27/2008 01:59 AM | To: "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx> cc: Subject: [equinox-dev] [prov] p2 for starters |
