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

[Dorian Birsan <birsan@xxxxxxxxxx>]

Mark, you can provide a patch for a
nested feature. The patch will  contain the plugins you want to update.

One can install/uninstall patches any
number of times. Patches will be disabled once the feature is updated as
part of the root feature update. 

-Dorian

Christophe Elek/Toronto/IBM@IBMCA
Sent by: platform-update-dev-bounces@xxxxxxxxxxx

06/08/2006 05:07 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

Yes, I remember my friend Peter Manahan screaming
about that
I believe you are right, that I only manage top root features :(

I am wondering if we did not fix it.. :(

Sorry, FYI , I was the designer of UM from 1.0->2.2... after that I
know
things have changed :)

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: pic04072.gif)
Web:http://www.ibm.com/software/rational/


                    
                     
                     
          
             Mark_Melvin@amis.    
                     
                  
             com        
                     
                     
      
             Sent by:      
                     
                     
To 
             platform-update-d    
    "Eclipse Platform Update component  
             ev-bounces@eclips    
    developers list."          
        
             e.org        
            <platform-update-dev@xxxxxxxxxxx>
  
                    
                     
                     
       cc 
                    
                     
                     
          
             06-08-2006 04:52    
                     
           Subject 
             PM        
               Re: [platform-update-dev]
Looking   
                    
                  for Recommendations
                
                    
                     
                     
          
             Please respond to    
                     
                  
             "Eclipse Platform  
                     
                    
             Update component    
                     
                   
             developers list."  
                     
                    
             <platform-update-  
                     
                    
             dev@xxxxxxxxxxx>    
                     
                   
                    
                     
                     
          
                    
                     
                     
          





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.
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev

Attachment: pic04072.gif
Description: GIF image