[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] Looking for Recommendations
|
Well, I've been up all night hacking
away with my new feature structure and porting my build to PDE 3.2 and
I finally managed to build an installed product and....it doesn't work.
<sigh>
So, I created my feature structure as
recommended - like this:
My Platform
|
+--C:\some\path\to\it
|
+--Core Platform Feature (branding and install handler)
|
+--Product 'X' Feature (for developing apps for Product
'X')
| |
| |
| +--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')
|
|
+--Core Development Feature (required
by ALL products)
|
+--Product 'Y' Core Feature (required
by all Product 'Y's)
The install went beautifully and exactly
as I thought it should. I was happy and excited. ;o) Then
I did a Help > Software Updates > Manage Configuration, and
I attempted to disable (and uninstall) Product
Y, which from what I understood
from all of these emails back and forth should have worked. However,
when I did this I got an error saying this would invalidate the current
configuration because Product X
required Core Development Feature.
Shite! I thought it *should* have detected that Product
X required the core feature
and disabled Product Y,
but not the feature that was required by Product
X?
Looking closer, it also appears that
the install did not actually go as planned either. According to a
file database I keep track of in my install handler, the installation of
the Core Development Feature shared
by both products was executed twice, so I have double the reference counts
on all my installed files. I'm not sure if this is a problem yet
or not....but if the platform detects a feature is present - why would
it install it again, apparently on top of itself?
So, now that I have re-architected my
entire platform...is this expected behaviour and I just misread the email
train, or what is going on? The only solution I can think of is to
make the Core Development Feature
optional in both of the products, but I would think this would break things
even more. The bottom line is I want to be able to remove one of
the installed products without breaking the platform. I thought this
configuration would allow me to do that?
Any help would be appreciated. I'm
supposed to release a drop tomorrow. :o(
Mark.
----------------------------------------------------------
Christophe Elek <celek@xxxxxxxxxx>
Sent by: platform-update-dev-bounces@xxxxxxxxxxx
06/08/2006 03: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
| "Eclipse Platform Update component
developers list." <platform-update-dev@xxxxxxxxxxx>, platform-update-dev-bounces@xxxxxxxxxxx
|
|
Subject
| Re: [platform-update-dev] Looking for
Recommendations |
|
Hey Mark, I will embed in the text as <ce></ce>
********************
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)
<ce> yep sounds good... at least it was the intent when we developed
it :)
</ce>
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.
<ce> Hmmmmm, are they the same product ? If so you could have the
branding
as the top and the product X and product Y as optional features... no ?
I am trying to remember if we have limitation with regards to branding.....
</ce>
So, assuming this is what you meant - I have some more questions ;o)
<ce> darn ! ;-) </ce>
1. 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?
<ce> Yes includes is for install and require
is for , well, not
really runtime as we do not run features :) I am wondering,
and I
should check, if includes does not mean requires...
I would put both... to be sure :) The real runtime
requirement is in
plugin.xml (or the OSGI now) </ce>
2. 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?
<ce> Yes, well... I believe we do dependency checking...
so if You ask
to disable feature A, I try to see which of the enabled
features need
feature A, if one needs it and is not about to be
disabled.. I do not
disable feature A... I believe the uninstall does
a disable first
</ce>
3. 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)
<ce> That is where the version number matters (at least until
3.0) , now
in OSGI you can specify if you need the exact version
or what you
tolerate
Let's say Product X needs feature A 1.0.0 and Product Y brings
feature A
1.1.0
If product X states: I can run with feature A 1.0.0 only, you cannot
install product Y (you will get a warning/error)
If product X states, I can run with 1.0.0 -> 1.9.9 then we will
bring
1.1.0, enable it, disable 1.0.0 and Product X and
Y will use
1.1.0.... In the config you will get a yellow triangle
for Product X stating: Product X was tested with 1.0.0 but 1.1.0
is now
enabled
</ce>
<ce> let me know... :) cheers </ce>
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?
<ce> the algorithm checks the 'best' version that satisfies
all
feature... if we cannot find one (conflict), then we fail to install
If product A states I need 1.0.0 exactly and Product B brings 1.0.1 but
states I can work with 1.0.0->1.9.9, then we use 1.0.0
Does it help ?
</ce>
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)
<ce> Np, I realized I over-engineered the model a bit... well,
lesson
learnt :) </ce>
Thanks,
Mark.
----------------------------------------------------------
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev
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.
