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

[Christophe Elek <celek@xxxxxxxxxx>]

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