2011-12-03 3 views
5

Ho scritto un bel plugin, che incorpora alcune sorgenti java generate.Eclipse PDE build/export plug-in/funzione/aggiornamento sito non onora la codifica dei file - come vietare la ricompilazione

Posso costruire il progetto bene. Posso eseguirlo in una configurazione di esecuzione che avvia un'altra eclissi e funziona a mio piacimento.

Così ho pensato: è ora di installarlo.

Quindi ho creato un progetto di funzionalità e un progetto di sito di aggiornamento e lo ho creato ed esportato e sembra che funzioni correttamente. Posso persino "installarlo" dal mio sito di aggiornamento, o esportare il plugin direttamente nel workbench in esecuzione. Vedo che è installato ma se provo ad aprire un file che potrebbe attivare il mio plugin, genera eccezioni. Nello specifico, mi dice che ci sono "problemi di compilazione non risolti".

Dopo una lunga ricerca, ricostruzione (nessun errore), ripetere il test di nuovo e di nuovo trovo un file logs.zip, con una directory il cui nome ricorda quello del mio plugin e in esso un file 54k (attenzione, è il 2011 e lo spazio su disco è estremamente scarso, ovviamente) con il nome divertente @dot.log. Quanto deve essere disperato cercare in un file del genere ?! Ma, sorpresa, sorpresa, si scopre ci sono 54K messaggi di errore come il seguente:

# 02.12.11 19:58:55 MEZ 
# Eclipse Compiler for Java(TM) 0.B76_R37x, 3.7.1, Copyright IBM Corp 2000, 2011. All rights reserved. 
---------- 
1. ERROR in X:\dev\frege\FregIDE\src\frege\IO.java (at line 1451) 
final public static Consts ij = new Consts(); 
          ^
Syntax error on token "Invalid Character", delete this token 

I "caratteri non validi" sono, naturalmente, i personaggi identificatori java perfettamente legali, è solo che non sono lettere ASCII. Questo è il motivo per cui ho tutti i file impostati su UTF-8, ho impostato UTF-8 come codifica predefinita, e come detto prima, con la normale build funziona perfettamente.

C'è un modo per impedire a Eclipse di ricompilare tutto quando esporto il sito di aggiornamento, la funzionalità o il plug-in. Questo è ciò che preferirei di più poiché tutto è già compilato e la ricompilazione richiede un altro minuto o giù di lì. (C'è anche una bandiera "file di classe Usare compilati nello spazio di lavoro." Ma sembra di fare nulla - semplicemente ricompila.)

Alternativa: Posso in qualche modo modificare lo script che utilizza per costruire questo? Non riesco a trovare lo script ant che usa per costruire. Se potessi cercare il passaggio di javac e inserire qui la codifica UTF-8. C'è una casella di controllo "Salva come Ant", ma il file Ant contiene solo:

<?xml version="1.0" encoding="UTF-8"?> 
<project default="feature_export" name="build"> 
<target name="feature_export"> 
    <pde.exportFeatures destination="x:\dev\frege\FregeUpdateSite" 
           exportSource="false" exportType="directory" 
           features="FregeFeature" useJARFormat="true"/> 
</target> 
</project> 

Come posso fare in modo che eclissi utilizzi le impostazioni corrette per la compilazione compilata se non riesco a impedirne la compilazione?

+0

scoperto nel frattempo che una possibile soluzione è quella di impostare '-Dfile.encoding = UTF-8' nel eclipse.ini – Ingo

risposta

7

Se si utilizza l'attività "pde.exportFeatures" per esportare da un'area di lavoro, credo che sia presente un attributo "useWorkspaceCompiledClasses" per utilizzare i binari dallo spazio di lavoro. Questo è equivalente alla casella di controllo nella procedura guidata di esportazione.

Si noti che l'attività pde.exportFeatures è un'esportazione dall'interfaccia utente ed è diversa da headless PDE/Build. Lo properties a cui Francis fa riferimento è per PDE senza testa/Build. Durante un'esportazione, PDE/UI li gestisce per te e non puoi cambiarli.

Il plug-in and feature specific properties influenzerà l'esportazione interfaccia utente, così come l'accumulo senza testa. (Ho sbagliato il link nel mio commento sulla risposta di Francis).

Suggerirei impostare la codifica in build.properties del plugin file invece di riutilizzare i binari di lavoro. Vorrei anche suggerire di creare un vero PDE/Build headless build invece dell'esportazione dall'attività dell'interfaccia utente.

+0

Grazie per la risposta. Per chiarimenti: perché raccomandate esattamente la costruzione senza testa? Mi consigliate in generale o solo per me perché posso quindi risolvere i miei problemi più facilmente? – Ingo

+1

È davvero un compromesso tra semplicità e controllo completo/personalizzazione. Non credo che una delle proprietà nel link Francesco ha dato sono disponibili con pde.exportFeatures, questo compito è la scelta di default ragionevoli per voi. Tuttavia, una build headless completamente automatizzata può essere complicata e c'è molto da imparare. Dipende davvero dalle tue esigenze, ma puoi creare una build headless di base che può quindi crescere e essere personalizzata man mano che ottieni più requisiti. –

6

È possibile utilizzare il file build.properties che fa parte della generazione PDE per impostare le opzioni di compilazione per la compilazione che è fatto nella build: http://help.eclipse.org/indigo/topic/org.eclipse.pde.doc.user/reference/pde_builder_config.htm (utilizzare l'opzione -encoding)

Non c'è modo che io sapere di usare i file di classe dal tuo spazio di lavoro nella compilazione.

+2

Vedere anche il "javacDefaultEncoding" e "javacCustomEncodings" proprietà che vanno nel file di build.properties del vostro pacco. Questi ti permettono di impostare la codifica per fascio o anche a livello di cartella/file. http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Freference%2Fpde_builder_config.htm –

+1

Mi piacerebbe dividere il bonus in mezzo a voi e Andrew. Se questo non funziona, otterrai il bonus (per essere il primo) e la risposta di Andrews sarà accettata. – Ingo

+1

Grazie Ingo, Andrew è davvero il tizio su questo mentre lavora sulla costruzione PDE. Sopprimerò molte delle sue cose per condividere la ricchezza. :) –