Re: [platform-update-dev] Configure/Unconfigure

[klicnik@xxxxxxxxxx]

Patrick/ Suyog, your guess is about right. Install/uninstall "move bytes", 
unconfigure/(re)configure just make the installed function unavailable/ 
available to the running eclipse. The custom install handler gets notified 
each time any of the actions are triggered (ref: prior thread in the 
mailing list) and what the install handler needs to do really depends on 
each situation.

However, your scenario 2 is the typical case. The non-plugin data will 
typically represent some additional executables, data, etc, that by itself 
is not seen, accessed or executed by the running eclipse. This extra data 
is generally meaningful only to some plugin(s) that you have also 
installed into eclipse at the time you installed the extra data. In the 
typical scenario if you unconfigure your feature (and consequently its 
plugins),  the extra data also becomes unavailable (because the plugin 
that knows what to do with it is unavailable).

So it would seem like your install handler only needs to worry about 
"moving bytes" and simply not implement the other methods (take defaults 
from the base implementation that do not do anything).





"Patrick Mueller" <pmuellr@xxxxxxx>
Sent by: platform-update-dev-admin@xxxxxxxxxxx
05/23/2002 08:22 AM
Please respond to platform-update-dev

 
        To:     <platform-update-dev@xxxxxxxxxxx>
        cc: 
        Subject:        Re: [platform-update-dev] Configure/Unconfigure

 

Vlad, Suyog and myself are working on this together.  We need to 
understand
both the user view of the different actions install, uninstall, configure,
unconfigure; and how to implement.  Implement is actually sort of 
grok-able
given the code, and your help :-)

I'm not sure that I've got the big picture of the end-user actions though,
and I'd like to see that.  Here's my guess:

- install: copy stuff from an install/update site into an eclipse-based
product's directory tree
- uninstall: delete stuff installed copied over
- configure: make the thing that was installed available to run
- unconfigure: make the thing that was installed unavailable to run

For plugins, this makes some sense; you install/uninstall new plugins; you
turn plugins on or off through config/unconfigure.

It's not clear what this might mean for non-plugin data, and I realize 
that
it's completely out of your scope to define what it means, but it would be
nice to see your thoughts on it.

Here are some potential scenarios.  In our case, our non-plugin data is
simply a jar/zip of files that will get layed down into the eclipse-based
product's directory tree.  We won't be touching anything in the eclipse 
tree
(except maintaining some state data in the feature directory, probably).
For instance, we have product directory tree:

xxx
    eclipse
        ... all the usual eclipse stuff here
    yyy
    zzz

We'll be populating files in yyy and zzz directories.

So, here some scenarios:

1)
- install/uninstall simply copy/delete our non-plugin file from the 
feature
directory
- configure/unconfigure populate/delete yyy/zzz directories from the 
copied
non-plugin file

2)
- install/uninstall populate/delete files in the yyy/zzz directories from
the transient non-plugin file
- configure/unconfigure do nothing related to the non-plugin file


2) seems easiest, since it doesn't require an extra step (configure).  It
seems unlikely that doing a scenario 1) configure/unconfigure to
populate/delete files really makes sense for our product.

----------------------------------------------------
pmuellr@xxxxxxx
----------------------------------------------------