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. Jeff "Tim Webb" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/03/2007 10:08 AM Please respond to Equinox development mailing list <[email protected]> To [email protected] cc Subject [equinox-dev] Re: [provisioning-dev] Equinox Provisioning M1 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? Congrats again, Tim On 8/2/07, Jeff McAffer <[EMAIL PROTECTED] > wrote: 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 [email protected] mailing list and bug reports to the Eclipse/Equinox/Incubator bugzilla bucket (use [prov] in the summary line). For more details (in progress) see: http://wiki.eclipse.org/Equinox_Provisioning_M1 The Equinox Provisioning Team _______________________________________________ provisioning-dev mailing list [EMAIL PROTECTED] https://dev.eclipse.org/mailman/listinfo/provisioning-dev _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
