[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-update-dev] Install handlers and SWT/JFace
|
I have this working, here's what I did so folks with a similar problem
have a starting point. I've left out the error handling to the
example's not too verbose.
- Created a class InstallHelper decending from BaseInstallHandler in
helper.jar
This install helper class resides in a jar file that's downloaded with
the feature. In the feature.xml file, there's the following line:
<install-handler library="helper.jar"
handler="com.your.package.InstallUIPart"/>
- helper.jar contains the class com.your.package.InstallUIPart that
implements Runnable
This is the class that will present dialogs and such to the user.
- In InstallHelper#initialize
// deprecated, I'm not smart enough to figure out how to do this via the
OSGi bundles interfaces
Plugin uiPlugin = Platform.getPlugin("org.eclipse.ui");
ContentReference baseRef =
feature.getFeatureContentProvider().getFeatureManifestReference(null);
URL base = null;
if (baseRef != null)
base = baseRef.asURL();
URL cp = new URL(base, "helper.jar"); // I should figure out how do
get this so it's not hard coded.
URLClassLoader urlLoader = new URLClassLoader(new URL[] { cp },
uiPlugin.getClass().getClassLoader());
Class dlgClass = Class.forName("com.your.namespace.InstallUIPart", true,
urlLoader);
Runnable o = (Runnable) dlgClass.newInstance();
o.run();
- In InstallUIPart#run
Display disp = new Display();
Shell sh = new Shell(disp);
Now that you have an instance of Shell, you can instantiate dialogs from
the Jface/SWT toolkits. :-)
The bit of magic (at least for me) was that I need to load the
InstallUIPart using the class loader of the UIPlugin so it would resolve
all of the imports correctly, but I could not cast that class to
InstallUIPart from the code loaded from helper.jar, because different
class loaders were used for each of the instances. However, the class
IRunnable was loaded by the same class loader, so I could cast without
generating an exception. If I need to invoke other methods, I'll need
to do so via reflection.
gene
-----Original Message-----
From: Dorian Birsan [mailto:birsan@xxxxxxxxxx]
Sent: Wednesday, September 08, 2004 10:54 AM
To: platform-update-dev@xxxxxxxxxxx
Subject: RE: [platform-update-dev] Install handlers and SWT/JFace
Yes, that's a good idea.
We created a custom class loader for webapps started by the tomcat
plugin. Take a look at org.eclipse.tomcat.
-Dorian
"Sally, Gene" <Gene.Sally@xxxxxxxxxxx>
Sent by: platform-update-dev-admin@xxxxxxxxxxx
09/07/2004 11:45 PM Please respond to
platform-update-dev
To<platform-update-dev@xxxxxxxxxxx>
cc
SubjectRE: [platform-update-dev] Install handlers and SWT/JFace
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
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev
