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
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
