|
|
|
|
|
|
Re: Export problems (fragment related) [message #436934 is a reply to message #436931] |
Tue, 20 September 2005 12:38 |
Daniel Krügler Messages: 853 Registered: July 2009 |
Senior Member |
|
|
Alex Blewitt wrote:
> Technically, it's not possible to depend on a fragment, only on
> another plugin. I'm not sure whether it's possible/feasible/sensible
> to have code from one fragment depend on code from another fragment,
> which is what this seems to be.
Actually it should be feasible to patch a fragment, at least considering
that fragments are now more than simple i18n helper, but also useful for
(temporary) bugfixing and allows access to package accessible members,
which otherwise can not be accessed to due to the class loader-related
problems, which you explained to me in my previous posting ;-))
Allowing to patch fragments would be consistent with Java capability to
get access to package visible items provided I open the same package.
Using a fragment was done to realize solve this problem.
Furtheron I don't understand why the problem occurs only for the export
process and **not** for the RCP app started by the run configuration!
> Given that it's a simple patch, I'd suggest modifying the source for
> the original SWT fragment and distributing that with your code, and
> then re-applying the patch for future versions that come out. That's
> what I did when a bug didn't get fixed in the 3.0 stream, and
> provided backwards compatibiltiy with 2.1 stream
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=38085
Hmmh, you mean I should modify the sources of Spinner and create a jar
with that modified source - Shudder!
I hope there exist another solution... I would try anything else first,
even obscure stuff like class loader context switches or similar. Do you
know a method to use class loader context switch to get access to the
package visible method in another plugin, but same package??
Thanks,
Daniel Krügler
|
|
|
|
Powered by
FUDForum. Page generated in 0.04076 seconds