Spécifique à l'architecture plug-in Eclipse Fragments

Question

Je dois cibler à la fois win32.x86 et win32.x86_64 architectures lors de la construction d'un plug-in RCP que les utilisations OS.getRegOpenKey (...). Les types des arguments en faveur de la méthode sont différents pour les deux architectures.

Je comprends maintenant qu'il n'y a aucun moyen simple d'avoir un fragment x86 ou x86_64 (en fonction de la construction) remplacer une méthode dans mon plug-in hôte.

Cependant, de ce post cela ressemble à une boîte de fragments, par exemple, ajouter une classe étend une classe dans l'hôte. Et le plugin hôte peut alors utiliser explicitement le ClassLoader pour trouver et instancier la sous-classe correcte du fragment inclus dans la construction de cette architecture. Que cela ressemblerait-il?

Answer 1

Sur la base de ce que j'ai jusqu'à présent liée à poste, c'est (construit sans erreur maintenant pour les deux architectures, et je juste besoin de voir si le construit application 64 bits fonctionne sur Windows 64 bits!):

plug-in assistant fragment Utiliser Eclipse pour créer les fragments x86 et x86_64. Les manifestes ont deux lignes supplémentaires ajoutée manuellement. Par exemple, les bits importants de Manifest.mf du fragment x86_64:

...
Bundle-SymbolicName: com.company.product.win32.x86_64;singleton:=true
Fragment-Host: com.company.product.win32;bundle-version="1.0.0"
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Eclipse-PlatformFilter: (& (osgi.os=win32) (osgi.arch=x86_64))
Bundle-ClassPath: src/,. 

Ensuite, a ajouté la sous-classe au fragment (utilisé le même nom de package en tant que super classe du plug-in hôte, mais qui est probablement pas nécessaire):

package com.company.product.win32;

import org.eclipse.swt.internal.win32.OS;
import org.eclipse.swt.internal.win32.TCHAR;

/**
 * Subclass the host's abstract OSUtilities
 */
public class OSUtilities64 extends OSUtilities {

    public String getRegKeyValue (String path, String key) {
         long [] phkResult = new long [1];
         if (OS.RegOpenKeyEx ((long) OS.HKEY_LOCAL_MACHINE, new TCHAR(0, path, true), 
             0, OS.KEY_READ, phkResult) != 0) {
    ...

Idem pour la classe OSUtilities32.

Ajout des fragments à la feature.xml contenant le plug-in host:

   <plugin
     id="com.company.product.win32"
     os="win32"
     download-size="0"
     install-size="0"
     version="0.0.0"
     unpack="false"/>
   <plugin
     id="com.company.product.win32.x86"
     os="win32"
     arch="x86"
     download-size="0"
     install-size="0"
     version="0.0.0"
     fragment="true"
     unpack="false"/>
   <plugin
     id="com.company.product.win32.x86_64"
     os="win32"
     arch="x86_64"
     download-size="0"
     install-size="0"
     version="0.0.0"
     fragment="true"
     unpack="false"/>

Ensuite, le plug-in hôte peut charger le statiquement approprié, classe disponible:

/**
 * Get class from appropriate fragment
 */
public static OSUtilities getOSUtilities() {
    ClassLoader loader = OSUtilities.class.getClassLoader();
    try {
        Class<?> cls;
        try {
            cls = loader.loadClass("com.company.product.win32.OSUtilities32");
        } catch (ClassNotFoundException e) {
            cls = loader.loadClass("com.company.product.win32.OSUtilities64");
        }
        OSUtilities util = (OSUtilities) cls.newInstance();
        return util;

Je devrais utiliser la propriété système d'architecture pour choisir qui instancier -. Plus tard,