| Product configuration/update design questions [message #120301] |
Tue, 28 October 2008 09:57 |
Eclipse User |
|
|
|
I am designing an RCP, p2-ized, Eclipse-based product and have some
product configuration\update site questions. I've studied Eclipse
documents and forums but could use more advice. Our product will be
delivered in several configurations. All configurations have basic product
launcher, branding, and common features, which I'll call the Core. Each
configuration has various, additional Features. For example:
Config 1 = Core + Features A,B,C
Config 2 = Core + Features A,D,E
etc.
We want users to be able to update their Configs to the latest components
via Update Site(s), and possibly extend their Configs by adding additional
Features. I'm struggling with how to do this in an efficient,
"Eclipse-correct" way.
My first approach was to make a separate Product for each configuration.
Although Product zips and repositories come right out of the PDE Product
Build scripts, I think a separate Update Site is then required for each
Configuration. That is, an Update to Config 1 would only safely apply to
Config 1. That seemed like a lot of Update sites. Next, I thought of the
Core by itself as a standard RCP Product, built with PDE Build scripts. It
could be supported by a Core Update Site with P2 Repository generated by
the scripts. Each Configuration could be made through Product Extensions
to the Core. E.g. Config 1 = Core plus Extension (A,B,C). The Extension
could be incorporated into the zip or product installer of Config 1 so
that the Base and Extension ultimately reside on the target PC. The
Features in the Extension could be supported by another Update Site with a
repository of all Features (A,B,C,D,E...). If this worked, only two Update
Sites would be required to support all Configs, one for the Core and one
for all other Features. Also, users of any Configuration could access
additional Features on the Feature Update site.
As a third approach, we could use Director to make Configurations. I.e. we
could make Config 1 by using Director to install Features A,B,C into the
Core. Although this would still require two Update Sites for all Configs,
it would result in a nice, tight package.
Are there better ways to handle Product configuration/update? Are these
approaches viable? Thanks,
MSacarny
|
|
|
Powered by
FUDForum. Page generated in 0.06119 seconds
Home