Fw: [platform-update-dev] Feature changes for 3.0

[Peter Manahan <manahan@xxxxxxxxxx>]

Injected a couple of comments below.
Overall it sounds ok though.


Thanks,

-----------------------------------
Peter Manahan
WebSphere Tools
Build/Install and 
Product Architecture
------------------------------------
manahan@xxxxxxxxxx
----- Forwarded by Peter
Manahan/Toronto/IBM on 11/11/2003 10:05 AM -----

[platform-update-dev] (no subject)

° From:
Dorian Birsan <birsan@xxxxxxxxxx>
° Date:
Tue, 4 Nov 2003 13:39:01 -0500 
° Delivered-to:
platform-update-dev@xxxxxxxxxxx

---

We have been doing some simplification
of the update/install component, mostly in the UI and some code refactoring
for supporting command driven operations, and now we're investigating the
update API's, including the xml specs.
One item that seems to play
a major role in the increased complexity (code-wise and the number of bugs
associated with it) is the <include> feature relationship.  The
include relationship has been introduced to allow features to be built
out of existing features, as opposed to having to always list all the plugins
needed.  The final plugin list is obtained by transitive closure.
However, in Eclipse 2.1 <include>
was no longer a strict include, it allowed more flexibility by using the
"match" attribute:
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-update-home/doc/working/feature_extensions_2.html
One main reason was to allow
updating of nested features independently of parents, and another reason
was to allow feature patching.
We would like to go back to
the previous direct include (no "match" attribute) and address
the two reason differently:
- treat <include> as ownership
and do not allow nested features to be updated independently of the parent
features 

<pm> 
that was the original intention
I believe. The policy items mentioned below would be required to help ensure
there were not updates/fixes applied by parties not 
owning the features. We need to
be able to prevent updates to WSAD for example from Eclipse.org for support
reasons. 
</pm>

- patches will no longer include
features, but only plugins.  A patch will be associated with a root
feature, and contain plugins from any nested feature.  A patch should
also be able to <include> other patches.


<pm>
Although in theory I consider this
to be a bad thing 
   <rant> 
         Plugins
should have one and only one owner/residence/delivery mechanism because
once you move into the range of hundreds of  plugins shipping in a
varity of products 
         
    it becomes important that they are controlled from one central
point. Else there are mismatches and errors and confusion ensures. Generally
those who argue against it only have to worry about
         
    a small set of plugins.
    </rant>

This is acceptable for patches
I guess as long as the policy below is implemented. 
</pm>

- if you have a need for a nested
feature needs to be updated independently of its parent, then don't use
<include> for it, but make it an imported feature, with the appropriate
match attribute. 

<pm>
        I
am not sure what use case this would be for? In general we'd  like
to have the whole product included under one umbrella feature. Currently
we can't because the
         
include option doesn't work across sites and we have three sites. So the
user sees 3 updates for the product when in reality there is only one update
eg 5.0->5.1). This bullet seems to indicate that
        that
would increase the number of updates visible to the user when in fact we
need them to decrease.  Unless this is the general case and the problem
of cross-site includes is being fixed :-)
</pm>

- in addition, we are playing with
the idea of a policy file that determines what can and can't be updated,
and from what update sites.


<pm>
     This seems
to me to be required in order to keep the current function. I assume it
would play a part when searching for updates as well? 
So if you find a site with an update
that isn't in the policy file you ignore it.  Addtionally it would
be nice if there were a way to add
</pm>
 
Please post any comments about
the proposed changes and, if they are breaking changes, please describe
your scenarios. 
Thanks,
-Dorian