[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [equinox-dev] [prov] p2 for starters

The bug I mentioned
https://bugs.eclipse.org/bugs/show_bug.cgi?id=195876

would be a great place to attach such a patch. No hurry...

susan


Inactive hide details for "Haigermoser, Helmut" <Helmut.Haigermoser@xxxxxxxxxxxxx>"Haigermoser, Helmut" <Helmut.Haigermoser@xxxxxxxxxxxxx>




          "Haigermoser, Helmut" <Helmut.Haigermoser@xxxxxxxxxxxxx>
          Sent by: equinox-dev-bounces@xxxxxxxxxxx

          03/27/2008 10:28 AM
          Please respond to Equinox development mailing list



To: "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
cc:
Subject: RE: [equinox-dev] [prov] p2 for starters


Hi Jeff :)
Sounds good, I'll provide you guys with a class that covers everything
we would need from such a helper/util,
please give me some time to actually learn what that is though, still
evaluating the framework.. :)
HTH,
Ciao, hh

-----Original Message-----
From: equinox-dev-bounces@xxxxxxxxxxx
[mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeff McAffer
Sent: 27 March 2008 18:15
To: 'Equinox development mailing list'
Subject: RE: [equinox-dev] [prov] p2 for starters

This is likely related to ProvisioningHelper which is another
interesting
utilty class.  It would be good to factor things to provide a simple API
to
much of this function.  Helmut, can you synthesize the ProvisioningUtil
and
ProvisioningHelper classes to make something that you think makes sense?
We'll have to see what to call it and where to put it and how to get it
but
the idea is attractive.  Keep in mind here that we absolutely have to
avoid
creating another "Platform" class.

Jeff

> -----Original Message-----
> From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Haigermoser, Helmut
> Sent: Thursday, March 27, 2008 11:11 AM
> To: Equinox development mailing list
> Subject: RE: [equinox-dev] [prov] p2 for starters
>
> 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.ProvisioningU
> t
> 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: equinox-dev-bounces@xxxxxxxxxxx
> [mailto:equinox-dev-bounces@xxxxxxxxxxx] 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"
> <Helmut.Haigermoser@xxxxxxxxxxxxx>"Haigermoser, Helmut"
> <Helmut.Haigermoser@xxxxxxxxxxxxx>
>
>
>
>
>
>
>
> "Haigermoser, Helmut"
> <Helmut.Haigermoser@xxxxxxxxxxxxx>
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
>
>
> 03/27/2008 01:59 AM
> Please respond to Equinox development
> mailing list
>
>
>
> To: "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
> 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@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

GIF image

GIF image

GIF image