| Understanding Eclipse-ExtensibleAPI and Eclipse-PatchFragment [message #453009] |
Thu, 20 July 2006 07:33 |
 Daniel Krügler
Messages: 853
Registered: July 2009 |
Senior Member |
|
|
Hello,
since Eclipse 3.1 I'm looking for a mechanism to extend
plug-in API which allows such extension. There exists several needs
for that: Adding nl support, deriving from classes, get access
to package visible entities.
Actually all this belongs to the domain of fragments and from theory
they should work as they currently exist.
But a severe problem occurs, if the source of patch or derivation
base class is another fragment itself. An important example are the
(widget) classes from org.eclipse.swt and the belonging
org.eclipse.swt.widgets package. Lets assume you need access to
Spinner.getSelectionText() on Win32, which has package visibility.
Regrettably you can only specify a plug-in, not another fragment
as host of a given fragment, where you would like to put the above
mentioned fixing code, see also
https://bugs.eclipse.org/bugs/show_bug.cgi?id=141741
Eclipse-PatchFragment does currently only inofficially exist, see also:
https://bugs.eclipse.org/bugs/show_bug.cgi?format=multiple&a mp;id=126687
but seems to allow patching of a fragment.
So I tested (Eclipse 3.2) something like this (Note: In Eclipse 3.1.2
I needed that to fix a problem in Spinner, which is now solved. But lets
use this as a simple example):
------------------------------------------------------------ --------
package org.eclipse.swt.widgets;
public final class SpinnerAccess {
public final static int getSelectionText(Spinner spinner) {
final int result = spinner.getSelectionText();
return result;
}
}
------------------------------------------------------------ --------
with the following manifest
------------------------------------------------------------ --------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: %fragmentName
Bundle-Vendor: %providerName
Bundle-SymbolicName: SomePrefix.eclipse.swt.patch; singleton:=true
Bundle-Version: 3.2.0.v3233o
Eclipse-PatchFragment: true
Fragment-Host: org.eclipse.swt; bundle-version="[3.0.0,4.0.0)"
Eclipse-PlatformFilter: (& (osgi.ws=win32) (osgi.os=win32) (osgi.arch=
x86))
Bundle-Localization: fragment
Export-Package: org.eclipse.swt.widgets
Bundle-ClassPath: .
------------------------------------------------------------ --------
but got compile errors for SpinnerAccess.getSelectionText ("Spinner
cannot be resolved to a type").
I have the impression that Eclipse-PatchFragment does only allow
*replacement* of existing classes, not access to existing ones, is that
correct? If so, I wonder why: Actually the use-case mentioned above
is probably one of the minimum intrusive ones and prevents me from
replacing my complete swt version by a homebrewn one.
Does there exist a solution for the given use-case *without* replacement
of jars of the host plugin/fragment?
Thank you very much,
Daniel Krügler
|
|
|
Powered by
FUDForum. Page generated in 0.05693 seconds
] 
Search
Help
Register
Login
Home
