Thanks Tim. Yes, this is an issue
we also saw. As it is the set up is somewhat LIFO. That is,
the last "product" installed takes over the profile. There
is a similar problem for example if you uninstall the current product.
We could change the config.ini product setting but have no idea what
to set it to! A few thoughts...
- In one sense it is a packaging problem.
If we had "agent function" and "agent product"
packagings then you could add agent function to the IDE and still be retain
the IDE product. Similarly you could uninstall the agent function
without modifying the product characteristics.
- Having to make multiple packagings
is a pain in the neck. Having packagings that explicitly identify
their "product" parts vs. their "functional" parts
would allow a provisioning system to ask "would you like to have Product
X take over this profile or simply add Product X's function to the profile"
(clearly not in such horrifying language). At uninstall time the
system would also be able to identify the available "products"
and ask the user which should take over the profile.
- Of course, we could also go the simple
root and not allow the product settings to be overwritten thus forcing
users to create new profiles if they want to have another product.
- More generally, there is a real problem
of merging and composing products. No matter what you do, at some
point there can only be one winner. One splash screen, one window
title text, one initial perspective, one window icon, ... We have
seen so many different (reasonable) demands and requirements in this space
that it really warrants a separate work area on "product customization
and integration". that is not to say we should just bail on
the problem but rather that the problem is quite complex and far reaching.
- it would be very interesting to look
at how we can ensure the provisioning platform is open enough to allow
these policy choices to be expressed.
"Tim Webb" <tim@xxxxxxxxxx> Sent by: equinox-dev-bounces@xxxxxxxxxxx
08/03/2007 10:08 AM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Congratulations on this delivery! We've been anticipating
this as a good time to start integrating in on a branch under Maya. I'm
looking forward to see how the two might align. In playing briefly
with M1 this morning, I first created a profile that had the SDK. Sure
enough, I was able to launch my workbench! I then added the agent
to the same profile. Next launch showed the product for the agent
instead of continuing to launch the SDK product. Is there a document
that shows the flow of how the config.ini for the target profile is built
based on the selected installable units?
It is with great pleasure (and just a bit of last minute fuss) that the
Equinox Provisioning team announces the delivery of its Milestone 1. Milestone
1, as the name implies, is our first step towards a new provisioning
system for Eclipse. We have hit most of the major items on the M1
plan and most importantly are well-positioned to acheive the M1 goal of
self-provision. That is, we will now use the new provisioning support to
install and manage the Eclipse environment that we ourselves use to write
the provisioning system.
Over the comming weeks we will undoubtedly find various issues and make
numerous improvements. We invite you along on that journey with the
understanding that this is M1. It is very early days and the road
will be bumpy in spots. Your ideas, insights, bug reports and contributions
are what will make this effort a success. Please direct comments
to the equinox-dev@xxxxxxxxxxx
mailing list and bug reports to the Eclipse/Equinox/Incubator bugzilla
bucket (use [prov] in the summary line).