Architecture-Specific Eclipse Plug-in Fragments

Question

Ho bisogno di indirizzare sia win32.x86 e win32.x86_64 architetture quando si costruisce una RCP plug-in che usi OS.getRegOpenKey (...). I tipi di argomenti per il metodo sono diversi per i due architetture.

Capisco ora che non esiste un modo semplice per avere un frammento x86 o x86_64 (a seconda della build) l'override un metodo nel mio ospite plug-in.

Tuttavia, da questo post suona come una lattina frammento, ad esempio, aggiungere una classe che estende una classe nell'ospite. E il plugin host può quindi utilizzare in modo esplicito il ClassLoader per trovare e creare un'istanza della sottoclasse corretta dal frammento incluso nella build che di architettura. Cosa sarebbe questo assomigliare?

Answer 1

In base alla collegata al post, questo è ciò che ho finora (costruisce senza errori ora entrambe le architetture, e ho solo bisogno di vedere se l'applicazione a 64 bit incorporata funziona su Windows a 64 bit!):

frammento di plug-in wizard di utilizzare Eclipse per creare i frammenti x86 e x86_64. I manifesti hanno un paio di linee extra aggiunti manualmente. Ad esempio, i bit importanti manifest.mf del frammento 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/,. 

Poi, sottoclasse aggiunto al frammento (utilizzato lo stesso nome del pacchetto della classe super-dall'host plug-in, ma che probabilmente non è necessario):

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) {
    ...

Lo stesso vale per la classe OSUtilities32.

aggiunti i frammenti al Feature.xml contenenti l'host di plug-in:

   <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"/>

Quindi l'host di plug-in in grado di caricare in modo statico il caso, di classe disponibili:

/**
 * 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;

dovrei utilizzare la proprietà architettura di sistema di scegliere quale istanziare -. Tardi