[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] ECF, Skype, and 64-bit systems
|
Hi Elias,
First thanks for the interest...and ideas and suggestions. I've applied
Peter's changes (moving the WindowsConnector class to the windows
fragment) and committed this to HEAD (these plugins BTW, are technically
part of skype4java...not ECF per se...so these plugins are hosted at
sourceforge.jp).
Ted is probably working with the changes right now...I have a couple of
thoughts below...but his working/building with these changes applied
will obviously tell the story.
Volanakis, Elias wrote:
Hi everybody,
BTW, just saw Peter's email. Judging from the latest CVS changes, I
believe he followed the same approach. I would also suggest adding
“Eclipse-ExtensibleAPI” to the com.skype plug-in.
Although we can do this if it makes a difference (I don't think Peter's
changes had this in it, so it hasn't been done yet), it's not very
desirable in general...as this is not 'good form' for Eclipse/Equinox
fragments.
Below is my shot at the problem.
The issue is that there is platform-specific code (WindowsConnector)
in a platform independent plug-in (com.skype). On the build machine
this code gets compiled against the org.eclipse.swt...linux fragment.
At runtime, on windows it runs against the org.eclipse.swt...win32
fragment and breaks.
I think this is right. Specifically, where it seems to break is in the
use of the (swt) Callback.getAddress() method (in , which, on 32-bit SWT
impls returns an int, and on 64-bit impls returns a *long*).
I believe the solution is to put the WindowsConnector into a
platform-specific
com.skype...win32 fragment and not have in in the com.skype plug-in.
Hopefully PDE Build is then smart enough to compile this against the
org.eclipse.swt + org.eclipse.swt.win32... fragment.
This is possible, but I don't think it's likely, unfortunately. Reason I
say this...I think that the wiindows fragment code will compile just
fine on 64-bit linux (by loading/using the 64-bit linux version of swt
Callback class)...which would be incorrect...if it *does* somehow use
the win32 swt fragment then I agree with you that all would be
well...but am a little doubtful...Ted will have the final word though :).
This also touches a second problem with the com.skype plug-in. It
requires the
org.eclipse.swt bundle. However by inspecting the code, I believe that
the dependency is only needed for the WindowsConnector and there is a
fall back mechanism if SWT is not present (Win32Connector). Currently
a non-availability of SWT will result in the com.skype plug-in not
resolving and *prevent* normal operation of the plug-in.
Yes, this is a good point. If we can remove the dependency on SWT from
com.skype completely, that would be a much better organization (and
allow the com.skype plugin to run in environments that do not have SWT
at all (i.e. servers).
To address both issues I've tried these changes:
- Creating a com.skype.swt.win32.win32.x86 fragment. This fragment has
a dependency to org.eclipse.swt. The WindowsConnector is placed in
that fragment. The com.skype plug-in itself has now *no* dependency to
org.eclipse.swt.
Note that there are now two windows fragments, one for the SWT-based
connector (com.skype.swt.win32.win32.x86) and one for the plain
connector (com.skype.win32.win32.x86)
- For uniformity and discouraging developers from using the platform
specific connectors directly, I've moved the packages
com.skype.connector.{osx,linux,windows} from the plug-in into
respective fragments.
- Added "Eclipse-ExtensibleAPI: true" to the MANIFEST.MF of com.skype.
This is so that PDE can deal with fragments contributing Java classes
to the plug-in (see Eclipse Help).
- I took the liberty of using 0.3.0 as the version in all fragments.
Unfortunately I don't have a linux machine around, so I would be glad
if somebody could give it a try and let my know if this helps.
Yeah, I think this is a good idea (to try it out). I think your
reorganizations are fine...and will help with clarity. Note that the
reason it's like this now is that the skype4java code isn't really
'owned' by ECF (it's from the skype4java project), which is led by Koji
Hisano. The com.skype plugin is a pretty much a direct 'bundlified'
version of skype4java, while the fragments (up to now) have been used
for providing native code only (i.e. no java). So I (Scott) am the only
one on ECF that has commit rights to the skype4java codebase
(unfortunately at this point...as I don't want to be the bottleneck to
trying out the different organizations).
But, in any event, although I'm supportive of your suggested changes,
I'm less than completely confident it will deal with the 64-bit linux
compile issue...because I think whether the WindowsConnector is in a
fragment or a plugin, when the 64-bit PDE compiler goes to load the
Callback class (from *swt*) it will likely just load the Callback/64 bit
version (where getAddress returns long)...which will be wrong. You may
very well be right that the PDE compiler somehow knows to load the
Callback/32 class from swt (assuming it's available), given that the
fragment is a win32 fragment, and I'm hoping you are right! Ted will let
us know soon...
Thanks again for the help. It's appreciated.
Scott
Regards,
Elias.
---
Elias Volanakis
Technical Lead
Innoopract, Inc.
351 NW 12th Avenue
Portland, Oregon 97209
Tel: +1-503-552-1457
Fax: +1-503-715-4915
Mobile: +1-503-929-5537
evolanakis@xxxxxxxxxxxxxx
http://eclipsenuggets.blogspot.com
------------------------------------------------------------------------
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
