[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] Looking for Recommendations
|
Hi Christophe,
Thanks for the reply. Currently
all of my features and plugins are on the same site and the same location.
OK, so if I understand this I could
just create an update site containing my leaf features like you suggested:
My Update Site
|
+--Product 'X' Feature (for developing apps for Product
'X')
|
+--Product 'Y' Feature (for developing apps for Product
'Y')
So, then in my feature.xml for these
features, I would include as nested features all of the features I need
to run? So, for example, if I did a Help > Software Updates >
Manage Configuration on my product it would look something like this:
My Platform
|
+--C:\some\path\to\it
|
+--Product 'X' Feature (for developing apps
for Product 'X')
| |
| +--Platform
Core Feature (branding)
| +--Install Feature (custom install
handlers)
| |
| +--Core
Development Feature (required by ALL products)
| |
| +--Product
'X' Core Feature (required by all Product 'X's)
|
|
+--Product 'Y' Feature
(for developing apps for Product 'Y')
|
+--Platform
Core Feature (branding)
+--Install Feature (custom install
handlers)
|
+--Core
Development Feature (required by ALL products)
|
+--Product
'Y' Core Feature (required by all Product 'Y's)
Looking at the above, I am still tempted
to factor out the branding and install features into a top-level "Core
Platform Features" feature, and not nested in the products, but I'll
mull that one over. It would mean one more entry in the update site
to check off when you performed an update.
So, assuming this is what you meant
- I have some more questions ;o)
- If I nest features like this,
do I still declare a dependency that Product 'X' requires those features
that it is nesting? If the "requires" clause only means
that the required features and plugins must be present *before* installing
Product 'X', then I would assume I do not declare the dependency. Although
- this seems counter-intuitive to me because Product 'X' *requires* those
feature to function correctly...although it is including them... Hmm...so
I guess the dependency here is an "install-time" dependency rather
than an execution-time one?
- You're also saying if I decide
to disable/remove Product 'X' above that the *duplicate* features it nested
will not be disabled/removed because Product 'Y' still needs them? I
assume you hold some sort of reference count somewhere?
- Updating. I realize this
will be an issue as it is an issue now, but I'm not sure how this is going
to work. If I update Product 'X' only in the scenario above I assume
the update site will install the latest version of all of its nested plugins
and features as well. This will undoubtedly affect Product 'Y' -
which is OK, because that's the way it works now - you must upgrade everything
at once or you break your platform. However, let's say the user does
the wrong thing and only installs an update for Product 'X' (and hence
all of its sub-features). What happens to Product 'Y' (this is the
part I am the foggiest on)? Does it:
a) Continue to try to function, using
the updated versions of its nested features installed as a side-effect
of the update to Product 'X'?
b) Attempt to use the versions of the
plugins and features specified in its feature.xml - which are no longer
active because they have been upgraded?
c) Disable itself because it is all
screwed up. ;o)
I guess what I don't fully understand
is what exactly happens when a feature is installed and is declaring that
it contains a nested feature (or plugin) of version 1.0.0 (for example),
and by some other mechanism, that feature (or plugin) has been upgraded
to v1.0.1? And does this behavior depend on what order the features
are loaded/activated? What if in the above scenario, Product 'Y'
is actually parsed/loaded/activated first, referencing the *older* versions
of the nested features and plugins, and then the Product 'X' feature is
loaded?
Sorry for all the questions, but the
reason I am in such a state today is because I really don't "get it"
100% just yet. I'm almost there, though! ;o)
Thanks,
Mark.
----------------------------------------------------------
Christophe Elek <celek@xxxxxxxxxx>
Sent by: platform-update-dev-bounces@xxxxxxxxxxx
06/08/2006 12:54 PM
|
Please respond to
"Eclipse Platform Update component developers list." <platform-update-dev@xxxxxxxxxxx> |
|
|
To
| "Eclipse Platform Update component
developers list." <platform-update-dev@xxxxxxxxxxx>
|
|
cc
| platform-update-dev@xxxxxxxxxxx, platform-update-dev-bounces@xxxxxxxxxxx
|
|
Subject
| 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.
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.
