Re: [platform-update-dev] Looking for Recommendations

[Mark_Melvin@xxxxxxxx]

Thanks again, Christophe.  I'll
digest your responses and do some more prototyping before responding in-depth.
 I am starting to see the light!  ;o)  
I have just stumbled across one bit
of behavior though that I think I need to ask you about.  It looks
to me like if I nest features, there is no way to deploy an update to a
sub-feature directly without actually rev'ing at least the top-level feature,
and perhaps even all of the parent features right up to the top-level.
 Is this true?  For instance, if I have something like this:

My Platform
   |
   +--C:\some\path\to\it
        |
        +--Top-Level Feature (my.top.feature v1.0.0)
             |
             +--Sub-Feature (my.sub.feature
v1.0.0)


And then I made an update site project
with a single update to "Sub-Feature", and one of "Sub-Feature"'s
plugins, and the platform failed to find any updates.  If that didn't
make sense, my site.xml looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<site>
   <feature url=""
id="my.sub.feature" version="1.0.1">
      <category name="My
Category"/>
   </feature>
   <category-def name="My
Category" label="This is a category">
      <description>
         This
is a description.
      </description>
   </category-def>
</site>

I then went into Help > Software
Updates > Manage Configuration and clicked on "Sub-Feature",
and there is no option to scan for updates.  Is this enforced for
a reason?  If all of the dependencies are maintained, why can't I
randomly update any sub-feature I want?
I guess this means if you installed
the SDK version of Eclipse you can't update your JDT unless you guys actually
deploy an incremental release to the SDK feature as well?


Mark.
----------------------------------------------------------


platform-update-dev-bounces@xxxxxxxxxxx wrote on 06/08/2006
03:54:31 PM:

> 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.