Hi Farokh,

I might be wrong, but you might want to look further into touchpoints,
which, as far as I understand it, are arbitrary code to execute during
installation. One such touchpoint could probably simply launch your
executable.

Regarding mailing-lists, p2 actually split off to a separate mailinglist (
[EMAIL PROTECTED]).

Greetings,
Fredrik.

On Mon, Aug 4, 2008 at 18:04, Farokh Morshed <[EMAIL PROTECTED]> 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
>
> _______________________________________________
> equinox-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Reply via email to