[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [equinox-dev] [prov] p2 for starters
- From: Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>
- Date: Thu, 27 Mar 2008 10:02:54 -0700
- Delivered-to: email@example.com
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?
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.
"Haigermoser, Helmut" <Helmut.Haigermoser@xxxxxxxxxxxxx>
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
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!! :)
[mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Susan Franklin
Sent: 27 March 2008 15:49
To: Equinox development mailing list
Subject: Re: [equinox-dev] [prov] p2 for starters
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:
>- Can you suggest a strategy on how to best filter a repos content,
>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
>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
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...
Inactive hide details for "Haigermoser, Helmut"
Sent by: equinox-dev-bounces@xxxxxxxxxxx
03/27/2008 01:59 AM
Please respond to Equinox development
To: "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
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:
-- 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
- 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
I know, many dummy questions, sorry for that :)
equinox-dev mailing list
equinox-dev mailing list