Hi, again ProvisioningUtil started out as a copy and then an evolution of ProvisioningHelper and for the most part attempts to be ui neutral. Can you annotate this bug with your comments regarding ProvisioningUtil?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=195876 I agree that it makes sense for this code to live in a non-UI plug-in. And if you have any problems using query provider, please open a bug under Equinox>p2 and use [ui] in the bug title. I will see it faster that way. Also, a little context for you: Right now we are pushing really hard on finishing M6 and then feature-completeness for M7 so I don't know that these kinds of things will happen for 3.4 unless there is a timing issue for clients that pushes the priority up. Otherwise I would expect the "more flexible API" stuff to happen post-3.4 very early in the next release cycle. So we may find ourselves iterating patches or what-not to get you going, but don't take it as disinterest if these things don't get into the released code based immediately...and if you do need them sooner, let us know in the bug and we can try to accomodate. susan "Haigermoser, Helmut" <[EMAIL PROTECTED] To: "Equinox development mailing list" <equinox-dev@eclipse.org> driver.com> cc: Sent by: Subject: RE: [equinox-dev] [prov] p2 for starters [EMAIL PROTECTED] ipse.org 03/27/2008 08:11 AM Please respond to Equinox development mailing list Thanks Susan, that information is appreciated! :) I am already on the way implementing my own query provider and will let you guys know how this went, our workflow is certainly somewhat different to yours and this will probably prove your framework to be flexible enough if I succeed :) One small thing I stumbled over regarding the provisional APIs: There is this class, org.eclipse.equinox.internal.provisional.p2.ui.operations.ProvisioningUt il that would be a good helper class to use, it helps register repositories etc. However, it's a UI class rendering it unusable for us, the reason for it being a UI-class seems to be the ProvUIActivator class being used in service lookups, not sure if that can be changed... So, thanks for this first bunch of answers!! :) Chao, hh -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Franklin McCourt Sent: 27 March 2008 15:49 To: Equinox development mailing list Subject: 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 Inactive hide details for "Haigermoser, Helmut" <[EMAIL PROTECTED]>"Haigermoser, Helmut" <[EMAIL PROTECTED]> "Haigermoser, Helmut" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 03/27/2008 01:59 AM Please respond to Equinox development mailing list To: "Equinox development mailing list" <equinox-dev@eclipse.org> cc: Subject: [equinox-dev] [prov] p2 for starters Hi @ll :) We (Wind River) are evaluating the technology, can you guys help me understand some basics? - What's the difference between groups and categories, when should each be used? Is it a pure UI thing? - Is p2 allowing nested groups like these: - Repo -- Group A --- Group A.A -- Group B ? (From looking at the admin UI I only see nested groups of the same name showing different versions of the same group...) - We are thinking about encrypting both the repos and the binaries, will the framework ,either ECF or p2, help us in that? - 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... - What are "flavors"? - Why is there a separate tooling/config-IU that actually stores the touchpoint data? - How will uninstall work for binary content (thinking about a zip that gets unzipped during installation by the touchpoint and is not available during uninstall time)? - Will binary content be allowed to overwrite files (e.g.: new eclipse.exe rolling out will overwrite the original one)? Will this render uninstall/revert impossible? - 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? I know, many dummy questions, sorry for that :) Ciao, hh _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
<<inline: pic25111.gif>>
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
