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

[Dorian Birsan <birsan@xxxxxxxxxx>]

Peter, thanks for categorizing the high
level product requirements. This is a very good starting point and it would
be very beneficial if other interested parties will contribute their thoughts
here.
In addition to some of the simplifications
already done in 3.0, we plan some more, particularly in the startup process
and the sites/features/patches infrastructure.
See some quick comments below:

platform-update-dev-admin@xxxxxxxxxxx wrote on 12/08/2003
10:50:19 AM:

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

We all agree here, and to make sure we are addressing
the right issues, it'll be good if you can list some of the things you
are perceiving as particularly "messy".
To me, the startup/reconciler protocol (restarting
of eclipse with a reconciler app, etc.) is a good candidate. Another one
is the nested features with various version matching levels.

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

Is there anything over what is currently implement
in 3.0 (with site redirection via preferences) ?

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

We are investigating exposing of platform.cfg in a
"new and improved" public format, and expect that each product
will provide one to start with. This platform.cfg (likely platform.xml)
could define the sites and the associated install policy.

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

There has been some discussions about predefined configurations
and "profiles" support. Unlike the ui roles, this is about scoping
the features that will run.

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

Care must be taken so your point a) above won't be
invalidated. 

> 3.  Build 
>         How it works today: WSxx tools have approximately
100 
> features and 600 plugins including nl and documentation ones. 

Only that many?  :-)

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

Good point.

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

Give it a try with the current support in eclipse,
and let us know what needs to be improved. This is new function, so any
feedback is appreciated. For example, how do you expect licence approval
should work in this scenario? Are these commands sufficient, any serious
bugs/limitations? 
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-update-home/doc/working/documentation/standalone_update.html


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

Worth looking into, but I think the enablement is
there (as you said, you can implement chaining), so I'd consider this a
lower priority item.

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

With the current browser support in eclipse, I think
the text version won't be needed anymore.

>        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 :-) 

Check the current standalone commands (see above url),
there is flag for just testing the operation. Is this good enough?

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

We also plan to simplify the patching story a bit,
so we expect this to work much better.

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

I'd translate this in shorter download time. Even
with same (slow) speed, the less stuff to download, the better. There is
some basic level of partial plugin support, but the granularity is at file
level, not at file content level. In 3.0 it is possible to update a plugin
by providing only the files that have changed. We are looking at 3rd party
tools or implementing support for dealing with deltas at a more granular
level, such as files in a zip/jar.

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

Again, thanks Peter.

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

-Dorian