[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] [prov] Comments on wiki "Equinox p2 Shared Install Plan"
|
Hey James, this is alot of good information.
Would you have a chance to update the shared install scenarios document
to highlight some of the points? My gut feeling from reading your
comments is that most of what you suggest is do-able wrt the underlying
infrastructure but the current context is driving Andrew et al to express
things in a different way (that may or may not line up with your situations).
Andrew, can you point James to the best
place to capture the scenario information and integrate it with the other
doc you have?
Jeff
James D Miles <jdmiles@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
12/17/2007 02:44 PM
|
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx> |
|
|
To
| Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| Re: [equinox-dev] [prov] Comments on
wiki "Equinox p2 Shared Install
Plan" |
|
If I was looking at this from the perspective of only
RPM for the SDK, you would likely be close enough.
>> bundles.txt stored in user home.
>> YES. I would change that to stored in users workspace or preferable
>> user's configuration space.
> Yes, configuration space is more accurate. I just meant the
user's
> writable location (I'm thinking something like ~/.eclipse/p2).
That is ok as a default maybe. However this decision should be deferred
until runtime. A user might want to run multiple instances with multiple
configurations.
>> If bundles.txt is missing from the user's workspace then it needs
to
>> be populated with the shared bundles.txt.
> Why can't it just run from the shared bundles.txt?
Ahh. That was a bad paraphrase of what I thought you indicated. So if you
load the shared bundles.txt how do you get a user's bundle.txt? How long
do you use the shared?
>> If you want to populate the user's bundle.txt with sdk in shared
>> install then in can be driven as a root IU or profile. However
this is
>> a policy decision and should not be hard-wired as always happening.
>I don't know what you mean here.
One size does not fit all. One user might want bundle A from ABC and another
user might want bundle A from XYZ. The admin might want to provision a
limited functionality product for user A. And he might want to provision
prototype stuff for user B. This can all be driven through the profiles/IUs.
>> The act of provisioning the bundles also allows for the
>> unfolding/customizing of additional artifacts related to specific
>> bundles. An example of additional work would be creating user
ICONs,
>> setting environmental variables.
>>
>> What we are really talking about is running only a configuration
phase
>> to get the user's bundle.txt up to the latest. The phases collect,
and
>> install are not wanted.
>
> This is not ideal for the Linux distribution case. We want things
to be
> completely ready to go after the user installs the packages. .desktop
> files and other metadata is just shipped in the package and put in
the
> right place upon installation so there's no need for additional
> configuration in this case.
It is nice that you can still do that. That is far from ideal for us. We
have to be able to maintain our products in many ways, rpm being just one.
For instance the admin wants to upgrade a few bundles in the shared install.
One of the bundles may need the libpath modified to point to the new native
dll. If a bundle and IU can manage itself it is a lot easier. We also have
to support many platforms besides RedHat. By containing/managing bundle
artifacts on a bundle basis we are much more efficient. Only the bundle
developer needs to work on the change.
If the user is running multiple workspaces where one workspace uses jdk
A and one uses jdk B. It will be hard to manage the property differences
in an rpm.
Are you saying that an admin will only upgrade the shared install through
rpm and the update UI can not be used?
>> Materialize profile from running bundles.txt
>> I am suggesting it is better to materialize bundles.txt from the
>> profile.
>
> It's difficult and fragile to do profile manipulation with headless
> package installation. I'm specifically talking about the installation
> of additional bundles here: CDT, Mylyn, etc. Pascal mentioned
that he
> has some in-progress code that will allow the materialization of
> bundles.txt from the running instance and a set of root IUs.
I am not sure why it should be harder. One way or another we have to have
a profile/profile(s) that represents the configuration that the user will
run with. So after CDT is installed it seems that we would still need profiles
and rootIUs that represent the installation or we will not be able to make
decisions about updates. If we start driving from both ends it has to be
harder.
Andrew
Overholt <overholt@xxxxxxxxxx>
Andrew Overholt <overholt@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
12/17/2007 12:00 PM
|
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx> |
|
|
Hi,
On Mon, 2007-12-17 at 11:36 -0600, James D Miles wrote:
> bundles.txt stored in user home.
> YES. I would change that to stored in users workspace or preferable
> user's configuration space.
Yes, configuration space is more accurate. I just meant the user's
writable location (I'm thinking something like ~/.eclipse/p2).
> If bundles.txt is missing from the user's workspace then it needs
to
> be populated with the shared bundles.txt.
Why can't it just run from the shared bundles.txt?
> If you want to populate the user's bundle.txt with sdk in shared
> install then in can be driven as a root IU or profile. However this
is
> a policy decision and should not be hard-wired as always happening.
I don't know what you mean here.
> The act of provisioning the bundles also allows for the
> unfolding/customizing of additional artifacts related to specific
> bundles. An example of additional work would be creating user ICONs,
> setting environmental variables.
>
> What we are really talking about is running only a configuration phase
> to get the user's bundle.txt up to the latest. The phases collect,
and
> install are not wanted.
This is not ideal for the Linux distribution case. We want things
to be
completely ready to go after the user installs the packages. .desktop
files and other metadata is just shipped in the package and put in the
right place upon installation so there's no need for additional
configuration in this case.
> Materialize profile from running bundles.txt
> I am suggesting it is better to materialize bundles.txt from the
> profile.
It's difficult and fragile to do profile manipulation with headless
package installation. I'm specifically talking about the installation
of additional bundles here: CDT, Mylyn, etc. Pascal mentioned
that he
has some in-progress code that will allow the materialization of
bundles.txt from the running instance and a set of root IUs.
Thanks for the comments,
Andrew
(See attached file: signature.asc)_______________________________________________
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:
signature.asc
Description: Binary data
