Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-update-dev] Looking for Recommendations

Hi Everyone,

I have mailed this list before with my convoluted feature structuring issues in the past, but we have come to a crossroads with our product where we can make a breaking change and I would like to choose the best solution moving forward and implement it, cleaning things up once and for all.  I was hoping with the huge amount of update effort that went into Callisto I could get some feedback as to the best way to approach my particular situation.

Here's the scenario.  We have quite a few "products" that share between them a significant number of common functionality plugins.  A customer could have one or many of these products installed at once.  I originally grouped all of the common stuff into "core" features and then had all of the individual product features depend on this core functionality.  This worked out well and avoided duplication.  However, it quickly spiralled out of control on the update site as more stuff was generalized into yet more "core" features, and more products sharing those features were created.   Currently, when the user hits an update site we have something like the following:

My Update Site
     |
     +--Core Platform Features (required by ALL products)
     |        |
     |        +--Platform Core Feature (branding)
     |        +--Install Feature (custom install handlers)
     |
     +--Core Development Features
     |        |
     |        +--Core Development Feature (required by ALL products)
     |
     +--Product 'X' Features
     |        |
     |        +--Product 'X' Core Feature (required by all Product 'X's)
     |        +--Product 'X1' Feature (a product based on 'X')
     |        +--Product 'X2' Feature (another product based on 'X')
     |
     +--Product 'Y' Features
              |
              +--Product 'Y' Core Feature (required by all Product 'Y's)
              +--Product 'Y1' Feature (a product based on 'Y')
              +--Product 'Y2' Feature (another product based on 'Y')


So, if a user simply wants to install support for "Product X1" for instance, they have to install:
  • Platform Core Feature
  • Install Feature
  • Core Development Feature
  • Product X Core Feature
  • Product X1 Feature

This is similar to the whackload of dependencies you run into if you want to install and use a product that depends on GEF, EMF, JDT, etc.  This is quite common (TPTP, WTP) and in my opinion is fine for separate, interdependent  projects like this, but it doesn't fit my idea of a simple-to-obtain-and-use commercial product.  Ideally, what I want to have is something like the following:

My Update Site
     |
     +--My Platform Core Feature (invisibly nesting the install handlers and branding required by all)
     |
     +--Product 'X' Feature (for developing apps for Product 'X')
     |
     +--Product 'Y' Feature (for developing apps for Product 'Y')


I only break out the core platform stuff because our install handler features require an exclusive installation, so it seems logical to group it with the branding of the platform as well.  Then, all the user has to do is install one "leaf" feature which provides support for the product they want to develop for.  What confuses me is what exactly is the best way to deploy this??  As I see it I have two options:
  1. Keep the features and feature dependencies I have, but take all of the common stuff needed by all "leaf" features and deploy them as nested features.  Essentially invert the tree of features I have now.
  2. Get rid of all of the common core features I currently have, and re-include all of their constituent plugins in each leaf feature

I don't think #1 will work because then uninstalling Product 'X', would not be allowed because it would want to uninstall its nested features - which Product 'Y' also requires (and nests).  In fact, I'm not even sure if two installed features can nest the same dependent feature??

#2 seems to me like the way to go but just seems like an awful waste of space and duplication in terms of "deployment".  Especially given the number of common plugins we have.  I assume in this case, if I uninstall Product 'X' the platform would figure out in this case that Product 'Y' is still using Common Plugin 'Z' and not remove it, so the dependencies should all work.

Anyway, I am just trying to make this simple for my users.  Can anyone give me any pointers based on:
  • What issues you faced and conquered with Callisto
  • What you know may be coming in the future based on outstanding update issues found with Callisto
Any feedback or recommendations would be very much appreciated.

Thanks,
Mark.

----------------------------------------------------------
Mark Melvin, P. Eng
Member of Technical Staff, Software Tools
AMI Semiconductor Canada Company
611 Kumpf Dr., Unit 200
Waterloo, Ontario, Canada N2V 1K8
Tel: +1.519.884.9696 ext 2245
Fax: +1.519.884.0228
Email address: mark_melvin@xxxxxxxx
Internet: http://www.amis.com

"Silicon Solutions for the Real World"
----------------------------------------------------------
 
AMI Semiconductor - "Silicon Solutions for the Real World"
NOTICE: 
This electronic message contains information that may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.

Back to the top