[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ProbableSpam]Re: [equinox-dev] [prov] Thoughts on the engine
|
Another possible approach is to have
a single root IU, whose prerequisites have filters based on different classes
of users. Since the filters on required capabilities are evaluated
at install time based on properties in the profile, the result would be
that the same root installed into different kinds of profiles would yield
different install trees. This allows per-user customization without having
to build too much smarts into the repository itself. Of course, this does
require that the profile be seeded initially with the correct properties.
Pascal Rapicault/Ottawa/IBM@IBMCA
Sent by: equinox-dev-bounces@xxxxxxxxxxx
08/17/2007 08:42 AM
|
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx> |
|
|
To
| Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
|
|
cc
| Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
equinox-dev-bounces@xxxxxxxxxxx
|
|
Subject
| [ProbableSpam]Re: [equinox-dev] [prov]
Thoughts on the engine |
|
I'm sorry but I don't understand what you are trying
to achieve, nor what
the problem is.
The SDK IU is an artificial root that we create at metadata generation
time
to provide one entity to install and get the sdk. The presence of this
IU
does not prevent you to define "James SDK" IU. You should be
able to
compose and/or install directly from the other IUs since they are
completely independent.
For example if you were to install the "org.eclipse.core.runtime"
IU you
would get it and all its prereq, thing that we were not able to do before.
PaScaL
James D Miles
<jdmiles@xxxxxx.c
om>
To
Sent by:
Equinox development mailing list
equinox-dev-bounc
<equinox-dev@xxxxxxxxxxx>
es@xxxxxxxxxxx
cc
Subject
08/16/2007 05:16
Re: [equinox-dev] [prov] Thoughts
PM
on the engine
Please respond to
Equinox
development
mailing list
<equinox-dev@ecli
pse.org>
Do you mean that some operations must be done with
the actual user
being
identified?
Yes, if you are sharing an install (multiuser), each
user must be
configured separately. And to your point in <tangent
2> each user may
be managed differently.
<cotangent 2>
My thoughts were along these lines. Currently we have
an IU with id
"sdk" in the sample. This sample provides
no capabilities but only
list requirements to be installed. While it should
remain an IU it
should be categorized by subclassing or creating an
interface for all
of these: IU fragment, IU, etc. That would allow another
abstraction
that manages a description ("sdk") of what
can be installed. These
could me managed on a per user basis if that is what
is wanted.
</cotangent>
(Embedded image moved to file: pic08335.gif)Inactive hide details for "Tim
Webb" <tim@xxxxxxxxxx>"Tim Webb" <tim@xxxxxxxxxx>
"Tim Webb"
<tim@trwebb.c
om>
Sent by: (Embedded image moved to file:
equinox-dev-b pic03420.gif)
ounces@eclips
To
e.org
(Embedded image moved
to file: pic31381.gif)
"Equinox development
08/16/2007
mailing list"
03:40 PM
<equinox-dev@xxxxxxxxxx
g>
(Embedded
image moved to file:
Please respond to
pic15965.gif)
Equinox development mailing list
cc
<equinox-dev@xxxxxxxxxxx>
(Embedded image moved
to file: pic13816.gif)
(Embedded
image moved to file:
pic31066.gif)
Subject
(Embedded image moved
to file: pic15739.gif)
Re: [equinox-dev]
[prov] Thoughts on the
engine
(Embedded
image moved to file:
pic26985.gif)
(Embedded image moved to
file: pic08985.gif)
<tangent>
That said I must admit that I'm not super happy with
this solution
since to
make such a "fetch only" operation usable,
either the director would
have
to expose a "fetch" operation (but it would
also have to expose a
"install"
operation to solve the other pb mentioned by James),
or one would
have to
either author its own director (or at least extend
the current one)
which
is something we want to avoid. In the light of recent
discussions
with Tim
and others, I wonder if the director should not become
just a planner
that
returns a bunch on operations that needs to be performed.
The results
of
this planner would then be passed on to the engine
and a "target"
phase
could be specified. For example:
EngineOperation[] op = director.install(ius, profile1)
engine(op, "fetch"); //This means do the
operations but stop at
fetch.
</tangent>
This actually makes a lot of sense to me. It addresses multiple concerns
including being able to present to the user an accurate statement of how
much work needs to be performed, as well as allowing for much easier re-use
in server-side scenarios.
Do you mean that some operations must be done with
the actual user
being
identified?
<tangent id="2">
While probably not where you were going with this one, mentioning per-user
operations reminded me of another flow we were planning to support in Maya
where some software would only be available to certain users. If we were
using user-aware repositories as part of the resolution process, would
we
do the filtering inside the repository? If so, how would we handle this
in
a multi-user scenario especially when a director/planner is being used
server-side? Ideally I'd like the flexibility of filtering which software
is available to which user, but currently the implementation / APIs do
not
allow passing of any handle or request-identifier to the repositories to
aide in determining which software is available. Thoughts?
</tangent>_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
(See attached file: pic00393.gif)
_______________________________________________
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
Attachment:
pic08335.gif
Description: GIF image
Attachment:
pic03420.gif
Description: GIF image
Attachment:
pic31381.gif
Description: GIF image
Attachment:
pic15965.gif
Description: GIF image
Attachment:
pic13816.gif
Description: GIF image
Attachment:
pic31066.gif
Description: GIF image
Attachment:
pic15739.gif
Description: GIF image
Attachment:
pic26985.gif
Description: GIF image
Attachment:
pic08985.gif
Description: GIF image
Attachment:
pic00393.gif
Description: GIF image
