RE: [platform-update-dev] Install handlers and SWT/JFace

["Sally, Gene" <Gene.Sally@xxxxxxxxxxx>]

Dorian,

>> Please open a feature request on Platform Update
https://bugs.eclipse.org/bugs/show_bug.cgi?id=73424

>> I think you can expect to be able to specify UI dependencies for your
install handler
Do you have anything I could look at as a reference?  I can't see a way
of setting-up the classpath before my installhandler gets loaded.  And
since it has a bunch of imports for SWT and other things, it refuses to
load.  It seems to me I need to strip down my install handler to
something that fixes-up the classpath and then instantiates another
class that does the graphical bits.  Is there a good place to look for
an example of this sort of thing that comes to the top of your head?
I've been digging through Eclipse/CDT projects without any luck.

Thanks for all of the help.

gene
-----Original Message-----
From: Dorian Birsan [mailto:birsan@xxxxxxxxxx] 
Sent: Tuesday, September 07, 2004 6:12 PM
To: platform-update-dev@xxxxxxxxxxx
Subject: Re: [platform-update-dev] Install handlers and SWT/JFace



Yes, we've had some discussions on introducing a new attribute on the
install handler element, that would specify the context in which the
handler will run. Particularly, this context attribute would define the
plugin whose class loader to be used as a parent loader when
instantiating the class loader for the handler. 
I would like to first get in touch with the core team who're working on
the security model for eclipse, as install handlers may need to be
restricted to what they could do. But as a general direction, I think
you can expect to be able to specify UI dependencies for your install
handler. 
Please open a feature request on Platform Update. 

-Dorian



Dejan Glozic/Toronto/IBM@IBMCA 
Sent by: platform-update-dev-admin@xxxxxxxxxxx 
09/07/2004 05:51 PM Please respond to
platform-update-dev

Toplatform-update-dev@xxxxxxxxxxx 
cc
SubjectRe: [platform-update-dev] Install handlers and SWT/JFace











Install handlers are instantiated using the same class loader that loads
update core classes. This means that it only 'sees' classes that are on
the
dependency list of the Update Core plug-in. There is a good reason for
this: features with install handlers must allow command line
installation
i.e. when running in a headless mode (no UI). Obviously, a feature that
wants to put up a dialog during the installation cannot be installed
from a
command line.

In the past, Team component attempted to solve a similar problem in
repository providers by providing a type-neutral parameter call
'context'
(of type Object). Obviously, Team Core component has no idea what this
'context' object is, but Team UI component passes the parent shell
object,
allowing the client code to put up dialogs and other visual controls.
The
key is that this object can be null (when the provider is instantiated
in a
headless mode), so the provider implementers must have a strategy for
this
scenario.

I will let Dorian Birsan who owns Update take over the topic (in
particular
if the Team approach is possible in the context of Update).

Regards,

Dejan Glozic, Ph.D.
Manager, Eclipse Development 1A
D1/R0Q/8200/MKM
IBM Canada Ltd.
Tel. 905 413-2745  T/L 969-2745
Fax. 905 413-4850



 

            "Sally, Gene"

            <Gene.Sally@times

            ys.com>
To 
            Sent by:                  <platform-update-dev@xxxxxxxxxxx>

            platform-update-d
cc 
            ev-admin@eclipse.

            org
Subject 
                                      [platform-update-dev] Install

                                      handlers and SWT/JFace

            09/07/2004 05:28

            PM

 

 

            Please respond to

            platform-update-d

                   ev

 

 





Hi,

I've seen various posts (on this mailing list and others) about using
graphical widgets from a custom install handler but I haven't seen
anyone who got this working.  I'm trying to run a class in a jar file
packaged along with the feature, and apparently, the classpath in this
context does not have any references to the graphical plug-ins.

It appears like one solution to this problem is installing a feature
that registers a plugin under the
org.eclipse.update.core.installHandlers and then have the user run the
update manager again to install a feature that references the newly
installed installHandler which has the correct classpath and can then
present the user with dialogs, etc.  While a good work-around, I think
potential users would find this procedure a bit awkward.

Is there a way to configure an custom install handler that can use SWT?
If not, is there something on the road map?  Does an example or some
documentation for this usage pattern exist that I've managed to miss?
I'd sincerely appreciate any pointers you could send my way. :-)

FWIW, The installation I'm considering would require at least a few
dialogs worth of data during installation and it appears like, the best
route would be to use a third party tool to tackle this problem.


Thanks,

gene

_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev


_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev