[platform-update-dev] Product Requirements for Update Manager

[Peter Manahan <manahan@xxxxxxxxxx>]

Since Eclipse 3.0 is on the horizon
 and there have been some discussions of changing the way update manager
works. It had been suggested that this is a good time to revisit  the
product requirements. The current way update manager works with features/nested
features was to meet product requirements and the timeline to do so was
tight.  So the existing infrastructure was modified and twisted to
get it to work. 
Thereby making it messy :-) So as long
as the basic requirements that the current version of Update Manger already
handles is met I am all for making it less messy.

Here are the basic product requirements
from the WSxx tools point of view. I am sure others have their own as well
and will chime in.

I believe we can break these down into
several categories/topic. List'em first detail later.

1. Install/Update Policy   --  who,what
and where from 
2. Runtime        
                   --
  Scoped runtime. related to policy.
3. Build Time        
              -- the WSxx products currently
are  built with plugins and packaged via features for example
4. Install        
                     
  -- make it better at install time.
4. Usability        
                   --
making it less ugly to the users and easier  to apply fixes.


So starting with 
1. Install/Update Policy
        Basically
being able to set the policy on what gets updated from where and when.
The user should be able to change 
         this
policy in some cases.  One good case for the user being able to change
this policy is the ability to redirect the
         default
update site to an internal server within an  organization by their
IT dept.

        The default
case should be:
        a) Products
need to be the only ones able to update a their product sites. Currently
root features handle the scoping of where an update can 
           
  come from. We still need to have that kind scoping in place.
        b) Downloads
of new features/plugins shouldn't be allowed into the product directories
unless from an approved site. We own our directories
           
 With the work going on with better ways to link in sites this should.
        
2. Runtime resolution
          a)
One flaw currently in 1. a)  is that it is possible for a plugin outside
the main eclipse site to become active if it is a later version. 
           
   We'd like at product level to prevent external plugins at
higher level version that exists outside our "scope" to become
active. 
           
   Not all plugins just ones that we already ship.  example:
  WSAD ships org.eclipse.jdt_2.1.1 it resides in the eclipse
directory 
           
  of WSAD. What we would like is that if another site links in to
WSAD's eclipse instance that if the other site contains an
           
  org.eclipse.jdt_2.1.2 that the newer org.eclipse.jdt doesn't
get loaded.  
           b)
The ability to disable a feature and the plugins it contains.  The
rationale for this one was to reduce memory footprint, 
           
     performace,scope the available plugins and  allow
the user to disable something that may be affecting his instance. 
           
    The scoping of available plugins I think should be handled
by *roles* but  I heard roles were only runtime filters so 
           
     I am not sure using them will reduce memory footprint
or increase performance.
           
c) Need to be able to link multiple products together to form one product.

           
    This partially relates to bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=35037.

3.  Build
        How it works
today: WSxx tools have approximately 100 features and 600 plugins including
nl and documentation ones.
        To build
we use the plugin.xml requires and custom ant tasks to set the classpath
for each plugin before building.
        Once the
plugins are built we run a tool that creates the features based off a set
of templates. The templates just
       list the
feature id/name and version and just lists the includes/requires/and plugin
statements. The lists are just
       of id's with
no version or match information.  During the creation of the features
,the feature plugin versions and
       match statements
are resolved, and the  feature branding plugins are created.  Since
there are multiple WSxx tools 
       the feature
includes are also used for packaging as well as for the original purpose
in 1a) above. The features
       defined for
a product are scanned and the plugins packaged and zipped up in chunks.
Which we then pass around to 
       various product
teams.
    
       a)  We
still need to be able to build and package the plugins and features.  I'd
prefer using features to build the plugins though rather
        than the
reverse way we do it now. We do it backwards because of all the complications
with nested features and keeping versions in
       sync.
       
 4.Install
       a)  We
need the ability in the features to point to arbitrary datafiles/jars/licenses.
Currently you can do this with plugins via the archive flag. 
           
We'd like to be able to do it for data. The scenario occurs when you need
to update multiple products with the same non-eclipse 
           
portion for example a runtime. We'd like to only have one version of the
runtime hosted as they can be quite large. 
       b)  Command
line invocation of update manager function. You should be able to call
eclipse to update from the 
           
commandline via a native installer. This requires feedback from eclipse
on how its doing and what failure or success occurred.
       c) Multiple
install handler definitions - we are finding having only one installhandler
a pain. We want to be able to have handlers
          for
specific types of function. If we ship them as plugins before the updates
then our install handler is basically a chaining mechanism.
          (ie.
read a data file we ship with the feature which lists which installhandlers
to run and what to runthem on) It would be better
         if
this function was core to the feature.
      d) One license.
Currently we need to ship 2  licenses for every feature we wish to
install. If we could remove the need for a text license
           that
would make life sooooo much easier.
       e) Query
update manager. A native installer likes to check to see if anything will
break if they uninstall. We like to present the user with the option
           
If we could as the update manager if there was any problem when removing
x features and prompt the user with consequences it would be 
           
nicer than  just barfing when eclipse comes back up :-)

5  Usability
      a)  Require
that we be able to rollback a fix. Currently revert/save configuration
idea would have worked except
          that
when you created a new workspace that history was lost.The removal of the
.config from the workspace 
         (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=37686 ) and the ability to
delete features/plugins will help here.
       b) *Componentizion*
We are becoming more and more componentized. This means that we ship function
in chunks and products pick 
           
 up the chunks and put them together to make a product. From a service/support/install/build
point of view these chunks are 
           
 easy to work with and can sometimes be "shared". Currently
we use site's as large chunks of function and link directorys to bring
it 
           
all together. Changes to eclipse need to take this usage model into account
as it is becoming more and more prevalent.
        c) Download
Speed - anything to increase this.
       

This should be a good start for now.
As we drill down into it a few more may crop up out of the woodwork.

Thanks,

-----------------------------------
Peter Manahan
WebSphere Tools
Build/Install and 
Product Architecture
------------------------------------
manahan@xxxxxxxxxx