| RE: [equinox-dev] Does Eclipse support native installation scenarios? |
|
Yes, we have read about touchpoints in the Wiki. Touchpoints and P2 are one and the same as far as this
discussion is concerned. farokh From:
equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On
Behalf Of Fredrik Alströmer Hi Farokh, On Mon, Aug 4, 2008 at 18:04, Farokh Morshed <fmorshed@xxxxxxxx>
wrote: Our problems with adopting P2 is mounting. I am starting to doubt
whether P2 in 3.4 is really ready for prime time or at least our use. Use case: We want the user to launch our plugin's installation process
by simply clicking "Install…" in the Software Updates view.
This action would download the plugin and a native installation
executable (a window's MSI exe file). Then, the native installation
executable would be launched, user interacts with the native installation
process, and upon completion of the native installation process the
installation of the plugin proceeds. If something goes wrong during the
native installation, or user simply changes his mind and cancels, we don't want
the plugin to be installed at all. But it appears that P2 has no way for us to launch the native installation
executable. We have also thought about launching our native installation executable
upon first use of the plugin. We certainly would not want to do
this in the plugin's start method. That would violate the etiquette that
plugin start method take a very long time. So, we would leave this
initialization for after the start method, to the actual use of our
plugin. But, what if the installation failed. What if the user
changed his mind and decided not to install at all. How do we tell
Eclipse that this plugin is "dormant" and should be uninstalled by
the user, you know, something similar to how Eclipse behaves after a plugin
start method has raised an exception. Looks like we cannot just call the
plugin's stop method, the Plugin's stop method comment says "Clients must never explicitly
call this method". I feel like we are between a rock and a hard-place, or totally missing
something. My questions are: 1) Is the use case
above a "reasonable" use case in the eyes of the P2 project? 2) Is the use case
above supported in P2 now? 3) If not, will it
be supported very soon? 4) Should we
abandon P2 and use the old update manager for the foreseeable feature and count
on P2 to support this use case BEFORE the old update manager is deprecated? By the way, we will always have this native installer. Eliminating the
native installation is not an option for us. If this mailing list is not the proper place to discuss this matter, PLEASE
tell us so. Thank you. farokh
|