[platform-update-dev] General Feature Update functionality - extending t

[jason.wessel@xxxxxxxxxxxxx]

Before I run off to re-invent something that has already been done, I
thought I would ask here.

I could attach a word document that represents this e-mail if that would be
more useful, as it seems this e-mail is kind of hard to read.

The needs:
* To be able to update any file in the entire eclipse install (jvm and all)
via the update manager
* To update the native uninstaller information every time a new feature is
installed so it is properly uninstalled

The Questions:
* Has anyone done it this yet?
* Are there any examples of install-handlers for the external files
available?
  Note: I already created an example one that just unzips files into the
product root to gain some experience.


The plan:
Assuming that no one has done this I have laid out a plan to achieve what I
need.  Essentially at the plugin level I desire to create a plugin that can
represent groups of files in the install tree which can be managed and
updated.  I will call this new type of a plugin an "external tool plugin".
   - There are some special files inside a named plugin directory
      o The plugin directory contains a "state file" to indicate if the
feature is "active" or "inactive", this is to make it a bit easier for the
native installer to initially perform the install and set the state
      o The plugin directory contains a jar file which represents the
archive of files to be installed
      o The plugin directory will contain a external.manifest file which
acts as the "control" file to specify where the external files live, their
sizes, and attributes
   - All the dependency information would work the same as a standard plugin
   - The install methods work differently in that files are extracted to
various locations which could even be outside the eclipse tree (for instance
a compiler, and linker)
   - For a new install of a module that didn't exist before it works like
this
       o The external tool plugin installer reads the external.manifest file
to determine the relative location to install the files in the jar that came
with the plugin
	 o When installing a check has to be done and the user needs to be
prompted if there is a file to be overwritten. Essentially if they don't
overwrite the plugin functionality is corrupt and should be rolled back.
       o After the jar has been totally extracted, it can be removed, I
debated about keeping it because it could be used to more easily reinstall
later, but it is not really needed.
       o The external.manifest file is used to validate all the extracted
files, if something doesn't match coming out of the jar file, the external
tool plugin is corrupt and the user should be notified
       o upon success update the state file in the plugin directory to
"active"
   - The disable process
       o Assuming that a dependency check passes and the external tool can
be disabled without making eclipse useless, (like disabling the JVM) the
user is allowed to disable
       o The external plugin install handler re-jars all the files as
specified in the external.manifest and checks each one to make sure the
sizes of the files match, else prompt that there was corruption of the of
original plugin
       o After the jar process is complete remove the files
       o update the state file in the plugin directory to "inactive" 
   - Update scenario #1 - Updates of files that are not in use
       o First, the prior version of the external tool plugin is disabled
       o then the install process as described above is executed for the
update
   - Update scenario #2 - Updates of files that are in use
       o The external.manifest file would specify an "in use" flag for
special case files such as the JVM, eclipse.exe and possibly others
       o The disable handler works slightly differently in that it still
does the re-jar, but instead of deleting the files immediately, it appends
to a script called eclipse.boot in the same directory as eclipse.exe.
       o The install handler also works a bit differently.  It extracts the
files to a temporary location and appends move commands to a the
eclipse.boot script.  At the very end of the script eclipse.exe is invoked
       o Every time the external tool plugin handler updates the
eclipse.boot script it makes sure that the last line of the script is the
invocation of eclipse.exe

* The entry point to Eclipse.exe needs a special routine put in to search
for a file called Eclipse.boot at the same level as Eclipse.exe  This is
created by the activation sequence of the "external tool plugin" and will do
the following.
   - Move the Eclipse.boot to the TEMP directory then spawn a new process
for the Eclipse.boot, and exit immediately
   - It is the responsibility of the Eclipse.boot to sleep a few seconds if
it is moving the Eclipse.exe (so as to wait for it to terminate).
   - Having the Eclipse.boot be able to move files around that have been
unpacked solves the "in use problem" and allows any file to be arbitrarily
updated.

* While it not talked about above, there will be an extension point for
working with the native uninstaller.  Each operation that adds a new plugin
would register with the uninstaller such that it can be removed when the end
user finally decides to uninstall the master Eclipse install, or simply a
portion of it.


Future enhancements:
* Allow external pre-installed repositories to be linked into an existing
Eclipse installation so that they could be updated.
* Add a validate config to the Eclipse Update manager or an extension to
read all the file sizes and attributes from each of the external tool plugin
directories and print out what if anything doesn't match.

I welcome any and all comments.

Thanks,
Jason