1.0 Introduzione
2.0 Problemi noti e limitazioni
2.1 Commenti nelle pagine di origine degli editor XML di PDE
2.2 Operazioni degli Appunti nella vista delle proprietà
2.3 Problema durante l'importazione dei frammenti
2.4 Output previsto nella cartella bin/
2.5 Preferenze non funzionanti con le operazioni di importazione o esportazione
2.6 Operazioni degli Appunti non funzionanti nell'editor manifest delle funzioni
2.7
Scegliendo Elabora percorso di generazione, il progetto JavaTM non verrà più creato
2.8
ECLIPSE_HOME genera percorsi di classe sensibili ai numeri di versione nei percorsi di directory plug-in
2.9
La procedura guidata di importazione dei plug-in non consente l'importazione di plug-in con versioni diverse
2.10
Natura PDE richiesta per la verifica della sintassi dei manifest plug-in
2.11 PDE non conserva il layout del file manifest originale
2.12
Scegliendo Vai alla riga nell'editor manifest, la vista Struttura non è più disponibile
2.13
La procedura guidata Nuova funzione non genera il file build.properties
2.14
Scegliendo Aggiorna Classpath viene utilizzata l'origine dell'installazione errata
2.15 Nessun metodo per specificare il tipo di libreria plug-in
2.16
Librerie runtime esportate con più di 2 plug-in non incluse nel percorso di classe
2.17 I colori della pagina di origine PDE non
hanno effetto scegliendo Applica
2.18 Cartella delle icone non inclusa in
bin.includes di alcuni modelli PDE
2.19 Associazioni ai tasti Emacs non funzionante nei campi dell'editor manifest
Questa sezione fornisce informazioni sui problemi noti e le limitazioni relative a PDE (Plug-in Development Environment).
PDE fornisce diversi editor a pagine multiple che includono una pagina di origine non formattata. Di solito, gli editor che gestiscono i file XML (manifest di funzioni, frammenti e plug-in) memorizzano i commenti. Tuttavia, i commenti non vengono memorizzati se aggiunti prima dell'elemento XML radice o dopo l'ultimo elemento secondario contenuto nell'elemento principale.
I tasti di scelta rapida degli Appunti (Ctrl+X, Ctrl+C, Ctrl+V, ecc.) non funzionano negli editor delle proprietà che appartengono all'editor manifest plug-in PDE. Utilizzare il menu di scelta rapida per attivare queste operazioni.
Se uno spazio di lavoro contiene progetti binari per un plug-in ed un frammento che fa riferimento a questo plug-in, vengono aggiunte delle librerie di frammenti al percorso di classe del progetto plug-in specificato. Se si tenta di sovrascrivere il plug-in e il frammento con le versioni di un altra generazione, la cancellazione del frammento precedente potrebbe non avere esito positivo. In tal caso, ripetere l'operazione per recuperare lo spazio di lavoro. È necessario importare solo il plug-in e il frammento interessati.
PDE assume che tutti i progetti di plug-in e frammenti contenenti il codice Java hanno una o più cartelle di origine e output di generazione nella cartella bin/. Anche se è possibile modificare il nome della cartella di output nella finestra di dialogo Proprietà, il programma di avvio del workbench di runtime PDE non funzionerà correttamente se viene eseguita tale modifica.
Le preferenze indicate nella pagina delle preferenze PDE Piattaforma di destinazione non vengono conservate. Pertanto, non sono soggette a operazioni di importazione/esportazione nella finestra di dialogo Preferenze.
Le pagine GUI dell'editor manifest delle funzioni supportano i menu a comparsa che contengono le operazioni degli Appunti standard (ad esempio, tagliare, incollare, copiare). Tuttavia, nessuna di queste operazioni funziona per i widget strutturali (strutture ad albero ed elenchi). L'unico scenario in cui queste operazioni funzionano è costituito dai widget di testo nelle pagine Informazioni e Origine.
PDE elabora il percorso classi di generazione di un progetto plug-in
ricercando le associazioni di origine nel file build.properties
. Questo
file definisce il modo in cui vengono compilate le cartelle nelle
librerie runtime. In assenza di questo file, PDE elaborerà il percorso
di classe che non contiene cartelle di origine, restituendo errori di
compilazione. Il file build.properties
richiesto viene
generato dal PDE alla creazione di un nuovo progetto plug-in. Se il
progetto plug-in viene creato in un altro modo, aggiungere
manualmente il file build.properties
.
Consultare la Guida PDE per ulteriori dettagli sui formati
dei file build.properties
.
Di solito, i prodotti Eclipse vengono creati con i plug-in ubicati nella stessa directory ed ogni plug-in si trova nella
directory il cui nome include un ID plug-in e un ID versione (ad
esempio, "org.eclipse.ui_2.0.0
").
Se vengono utilizzati plug-in esterni durante la configurazione
dell'host, i nomi di directory di questi plug-in vengono visualizzati
nei percorsi di classe generati dal PDE. Questi percorsi di classe
sono sensibili alle modifiche apportate alle versioni dei plug-in
e devono essere rielaborati se la piattaforma di destinazione
utilizza numeri di versione differenti.
WebSphere Studio consente la coesistenza di due plug-in con lo stesso ID, ma con versioni diverse, se l'unico oggetto condiviso è la libreria runtime. Tuttavia, PDE non può gestire questi plug-in, perché crea dei nomi di progetti utilizzando gli ID plug-in durante l'importazione del progetto binario.
PDE può fornire solo la funzione di verifica della sintassi e i messaggi di errore/avvertenza per i manifest plug-in, se il progetto plug-in presenta una natura plug-in PDE. La procedura guidata PDE assegna automaticamente questa natura alla creazione del plug-in. Questa condizione si verifica solo se viene utilizzato un regolare progetto Java per ospitare un plug-in. Il problema può essere risolto convertendo il suddetto progetto in un progetto PDE.
Quando viene utilizzata una pagina Nessuna origine dell'editor manifest PDE, PDE converte di nuovo le modifiche in XML, rigenerando il file. Verranno conservati i commenti e l'intero contenuto, ma non il layout del file effettivo. Ciò potrebbe causare la visualizzazione di false modifiche durante il confronto dei file. Se il layout del file è importante, eseguire le modifiche nella pagina Origine. Altrimenti, non utilizzare le pagine Origine contemporaneamente. Poiché i file XML vengono generati in modo da rispettare e conservare l'ordine degli elementi principali (estensioni, punti di estensione, ecc.), le modifiche apportate in una pagina Nessuna origine di un editor manifest PDE, non determinano falsi delta durante il confronto dei file.
Quando viene richiamato il comando Origine > Vai alla riga nella pagina Origine dell'editor manifest PDE, la vista Struttura diventa grigia. Poiché la pagina Origine non dispone di una struttura funzionale, non si verifica un'effettiva perdita di funzionalità.
Durante la creazione di un nuovo progetto di funzioni, la
procedura guidata PDE non genera automaticamente un file
build.properties
. Di solito, la creazione della funzione
genera un file JAR senza contenuto. Per evitare ciò, creare manualmente un
file build.properties
, utilizzando le istruzioni fornite
nella Guida PDE.
Le librerie Java sono associate ai codici di origine a seconda dei percorsi specificati in una preferenza PDE. Per impostazione predefinita, questi percorsi vengono registrati dai plug-in dell'istanza WebSphere Studio durante la progettazione. Se la piattaforma di destinazione non corrisponde a quella dell'istanza di progettazione, il codice di origine fornito da questi plug-in non risulterà sincronizzato con le librerie. Pertanto, deselezionare i percorsi predefiniti e specificare dei nuovi percorsi del codice di origine che puntino ai plug-in nella directory di destinazione relativa all'installazione di WebSphere Studio.
Gli editor manifest PDE non forniscono widget per specificare i tipi di librerie runtime come "codici" o "risorse". L'unico modo per specificare questo attributo consiste nell'aggiungerlo manualmente all'interno della pagina di origine.
Se un plug-in richiede una libreria runtime esportata utilizzando più
di due plug-in, questa libreria non viene aggiunta automaticamente
al percorso di classe di compilazione durante la creazione del file
build.xml
. Esempio: il plug-in A esporta le librerie,
il plug-in B richiede il plug-in A e riesporta A, il plug-in
C richiede il plug-in B e riesporta B. Se il plug-in D richiede il
plug-in C durante la creazione del file
build.xml
, le librerie del plug-in A non verranno
aggiunte al percorso di compilazione anche se disponibili in fase di runtime. Il
problema può essere risolto nel seguente modo:
- Creare un
build.xml
utilizzando PDE (selezionare il fileplugin.xml
e fare clic su Crea JAR di plug-in)- Editare
build.properties
e aggiungere la seguente riga:
custom = true- Aggiungere i file JAR mancanti nel classpath dell'attività javac in
build.xml
.
Le modifiche ai colori che PDE utilizza per le pagine di origine degli editor a più pagine, non sono immediatamente visibili dopo aver premuto il pulsante Applica nella pagina Sviluppo plug-in > Preferenze editor. Per risolvere il problema, chiudere l'editor e riaprirlo.
PDE fornisce un numero di modelli che possono essere utilizzati per creare progetti
di plug-in completamente funzionanti e/o estensioni. Quando vengono i creati i progetti, il file
build.properties
viene creato con un contenuto iniziale, che comprende la proprietà
'bin.includes' che elenca il plug-in e il corrispondente codice
JAR. Tuttavia, omette gli altri file creati dal modello, ad esempio la cartella
icons/
. Tali file extra non verranno inclusi nel
plug-in durante la generazione mediante il file di generazione Ant o l'esportazione mediante la procedura
guidata 'Esportazione plug-in e frammenti di distribuzione'. Per evitare il problema, aggiungere file e
directory manualmente nel file build.properties.
Le associazioni ai tasti non predefinite non funzionano nelle pagine non di origine degli editor manifest PDE.
Visualizza il file Readme principale
(C) Copyright IBM Corporation 2000, 2003. Tutti i diritti riservati.