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

[Dorian Birsan <birsan@xxxxxxxxxx>]

Interesting scenario. I haven't tried
it before, but I think this may work:
When the SDK 1.0.1 is installed, its
nested features will actually be installed first, so your install handler
will execute first. There will be no restart after installing that nested
feature (amis.platform), so if there is a need for restart after the install
handler runs, then this won't work.

However, given the exclusive = true,
I think that kind of forces you to expose the feature on the update site.
Perhaps this would work:


Core Branding (and Install Handler) Feature (com.amis.platform)

My SDK Feature (com.amis.sdk)
 |
 +--Tools for Product X Feature (com.amis.productX)
 |
 +--Tools for Product Y Feature (com.amis.productY)

And have your SDK pre-req Core Branding.
That way, the user must select both for updates.

And finally, if you can put the install
handler in the sdk feature, then things will be straightforward.

-Dorian

Mark_Melvin@xxxxxxxx
Sent by: platform-update-dev-bounces@xxxxxxxxxxx

06/12/2006 11:28 AM

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
Subject	Re: [platform-update-dev] Looking for Recommendations

Thanks, Dorian. 

OK, here is another question.  What happens if I just simplify my
structure down to the following, basically mimicking the Eclipse SDK structure:

My SDK Feature (com.amis.sdk)
 |
 +--Core Branding (and Install Handler) Feature (com.amis.platform)
 |
 +--Tools for Product X Feature (com.amis.productX)
 |
 +--Tools for Product Y Feature (com.amis.productY)


Now, suppose I simplify my update site to only list updates for the core
SDK feature to avoid confusing the user.  All they need to know is
there is an update to the SDK.  So, my update site simply looks like
this: 


<?xml version="1.0" encoding="UTF-8"?>
<site>
 <feature url="" id="com.amis.sdk"
version="1.0.1">
    <category name="SDK Updates"/>
 </feature>
 <category-def name="SDK Updates" label="SDK Updates">
    <description>
       Updates to the SDK.
    </description>
 </category-def>
</site>


Now let's say I start with v1.0.0 of all features.  Now suppose that
we want to deploy an update to the SDK (to v1.0.1) that contains updates
to *both* the Core Install Handler feature, as well as the two Product
features, *BUT* the Core Install Handler feature is set to be installed
by itself with the exclusive="true"
attribute.  If I don't expose these updates on the update site, what
happens then?  The first time the user checks for updates, I assume
it will find an update to the SDK (from v1.0.0 to v1.0.1).  Does it
know that it has to install the Install Handler update first, then restart
and install the rest?   
I doubt it, so if not, do I have to expose these sub-features to the user
on the update site?  If so, how would that work with versioning?  I
mean, if the first time an update is run and the platform found a version
update from SDK v1.0.0 to SDK v1.0.1, how can you only install "part"
of that update?  I assume this is not possible, and I would then have
to make any features that must be installed exclusively a top-level feature?
 If so, this will sort of dictate my structure...

Thanks, 
Mark. 
----------------------------------------------------------


platform-update-dev-bounces@xxxxxxxxxxx wrote on 06/08/2006 06:14:46 PM:

> 
> 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 
> 
> 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" deleted by Mark Melvin/AMI] 
> _______________________________________________
> 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