| Re: [platform-update-dev] Looking for Recommendations |
Hello Mark,
Can you tell me why we cannot have just this ?
My Update Site
|
+--Product 'X' Feature (for developing apps for Product 'X')
|
+--Product 'Y' Feature (for developing apps for Product 'Y')
And let the feature.xml and <site archive tag> do the rest ?
When we designed the site.xml , our idea was to list 'only' what can be
'installable' (meaning product X or product Y)
Then the feature.xml of each product will describe what is included, what
is needed and what is optional
The archive tag (if present) can route to another part of the site or a
completely different site (like eclipse.org)
Uninstalling should work fine, we should only uninstall if no other enabled
feature requires this feature...
Are all your features in the same site and same location ?
Same for all your plugins ?
feel free to ping me :)
Christophe Elek - Senior Software Analyst
IBM Rational Serviceability Architect
IBM Toronto Lab 8200 Warden Avenue, Markham, Ontario, L6G 1C7
Phone Number: (905) 413-3467
Email: celek@xxxxxxxxxx (Embedded image moved to file: pic19577.gif)
Web:http://www.ibm.com/software/rational/
Mark_Melvin@amis.
com
Sent by: To
platform-update-d platform-update-dev@xxxxxxxxxxx
ev-bounces@eclips cc
e.org
Subject
[platform-update-dev] Looking for
06-08-2006 12:05 Recommendations
PM
Please respond to
"Eclipse Platform
Update component
developers list."
<platform-update-
dev@xxxxxxxxxxx>
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.
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev
Attachment:
pic19577.gif
Description: GIF image
