2010-11-11 6 views
5

Abbiamo un problema nel luogo in cui lavoro con riferimento a più progetti nel nostro codice. Fondamentalmente, abbiamo un prodotto, che chiamerò Leviatano. Questo progetto ha un certo numero di altre versioni, ognuna delle quali viene gestita come progetti separati in Eclipse. Come sviluppatori, in Eclipse di solito abbiamo più progetti (più versioni) aperti contemporaneamente, poiché riceviamo chiamate di assistenza su versioni precedenti (oltre a sviluppare simultaneamente più versioni).Come posso consultare le librerie in un altro progetto all'interno di Eclipse Helios?

Abbiamo anche il codice di prova, che è in un progetto diverso per ogni distribuzione di Leviatano. Io chiamo i miei progetti Leviathan_<branch name>. Così, per esempio, nel mio lavoro di Eclipse, potrei avere progetti come:

 
Leviathan_scott\ (my branch) 
Leviathan_9.2\ 
Leviathan_9.3\ 
Leviathan_10.0\ 
Leviathan_10.1\ 
Test_scott\ 
Test_10.0 

mio ramo è una copia del nostro tronco, in modo che possiamo considerare che la linea di sviluppo più attivo.

Il problema è che facciamo riferimento ad alcune librerie in Leviathan \ lib nel nostro codice di test. Ogni sviluppatore può nominare i loro progetti in modo leggermente diverso. Quindi, nello sviluppo del progetto di prova .classpath, facciamo riferimento al progetto Leviathan \ (senza aggiunte). Il percorso di classe per questo progetto (che è controllato nel nostro sistema di controllo del codice sorgente) potrebbe essere simile:

<?xml version="1.0" encoding="UTF-8"?> 
<classpath> 
    <classpathentry excluding="**/*.MySCMServerInfo" kind="src" path="src"/> 
    <classpathentry kind="lib" path="lib/abbot-1.0.2/abbot.jar"/> 
    <classpathentry kind="lib" path="lib/abbot-1.0.2/costello.jar"/> 
    <classpathentry kind="lib" path="lib/dbunit-2.4.8/dbunit-2.4.8.jar"/> 
    <classpathentry kind="lib" path="lib/easymock-3.0/easymock-3.0.jar" sourcepath="lib/easymock-3.0/easymock-3.0-sources.jar"> 
     <attributes> 
      <attribute name="javadoc_location" value="jar:platform:/resource/Test/lib/easymock-3.0/easymock-3.0-javadoc.jar!/"/> 
     </attributes> 
    </classpathentry> 
    <classpathentry kind="lib" path="lib/objenesis-1.2/objenesis-1.2.jar"/> 
    <classpathentry kind="lib" path="lib/privilegedAccessor-1.0.2/privilegedAccessor_1.0.2.jar"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-core/unitils-core-3.1.jar" sourcepath="lib/unitils-3.1/unitils-core/src"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-database/unitils-database-3.1.jar"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-dbmaintainer/unitils-dbmaintainer-3.1.jar"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-dbunit/unitils-dbunit-3.1.jar" sourcepath="lib/unitils-3.1/unitils-dbunit/src"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-inject/unitils-inject-3.1.jar"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-mock/unitils-mock-3.1.jar" sourcepath="lib/unitils-3.1/unitils-mock/src"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-orm/unitils-orm-3.1.jar"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-spring/unitils-spring-3.1.jar" sourcepath="lib/unitils-3.1/unitils-spring/src"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-testng/unitils-testng-3.1.jar" sourcepath="lib/unitils-3.1/unitils-testng/src"/> 
    <classpathentry kind="lib" path="data"/> 
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-core/lib/ognl-2.6.9.jar"/> 
    <classpathentry kind="lib" path="lib/testng-5.14.1/testng-5.14.1.jar" sourcepath="lib/testng-5.14.1/testng-5.14.1-src.zip"/> 
    <classpathentry combineaccessrules="false" kind="src" path="/Leviathan"/> 
    <classpathentry kind="lib" path="/Leviathan/lib/slf4j-api-1.6.1.jar"/> 
    <classpathentry kind="lib" path="/Leviathan/lib/hibernate3.jar" sourcepath="/Leviathan/lib/src/hibernate-3.6.0-src.zip"/> 
    <classpathentry kind="output" path="classes"/> 
</classpath> 

Quando uno sviluppatore carica il progetto di test nel suo/la sua postazione di lavoro individuale Eclipse, lui/lei avrebbe bisogno di collegare il progetto al progetto Leviathan originale andando su Preferenze-> Percorso di costruzione Java-> Progetti e aggiungere il progetto Leviathan_scott.

Il fatto è che, ovviamente, non viene modificata nessuna delle voci <classpathentry ... > che fanno riferimento a "Leviathan \ lib". Quindi, dobbiamo fare una delle due cose:

  1. Cambiare tutti i riferimenti da Leviathan a Leviathan_<branch name> nella mia .classpath utilizzando un editor di testo trovare/sostituire.
  2. Rimuovere tutti i riferimenti a Leviathan * .jar in Java Build Path e aggiungere nuovamente i jar in Leviathan_scott * .jar.

Il problema di queste è che deve essere fatto ogni volta il .classpath è cambiato, il che rende entrambe queste sembrano tutt'altro che ideali. Il nostro classpath non è cambiato super-regolarmente, ma direi che è cambiato una o due volte ogni due settimane. Mi piacerebbe essere in grado di collegare il mio progetto e devo eseguire solo un singolo passaggio per collegare questi progetti.

Sembra che potremmo impostare una variabile di ambiente all'interno di Eclipse e aggiungerla nelle voci .classpath. Ma ora abbiamo un problema perché se abbiamo molti progetti di test nel nostro spazio di lavoro che vogliamo compilare, questo non funzionerà. Entrambe le voci .classpath dei progetti di test faranno riferimento alla stessa variabile di ambiente, che ovviamente può solo indicare una posizione di super progetto.

Sembra che dovrei essere in grado di farlo, ma non so esattamente come ottenerlo in Eclipse. Qualsiasi pensiero sarebbe molto apprezzato.

~ Scott

+0

Apache Maven risolve questo tipo di problemi come un incantesimo. –

+0

D'accordo, ma è difficile convincere 20 sviluppatori a passare a un nuovo sistema di build ... Se dovessimo * assolutamente * doverlo, potrei essere in grado di spiegarlo, ma se è possibile fare a meno di questo, allora io Mi piacerebbe farlo in quel modo. – jwir3

risposta

2

Provare ad usare le 'Classpath Variables' di Eclipse.

Window->Preferences->Java->Build Path->Classpath Variables 

definire una o più variabili di tipo "Leviathan_under_test" e puntarlo alla versione che si desidera testare. Quindi, nel percorso di costruzione del progetto, modificare il riferimento della libreria per includere la variabile.

Quando si modifica la versione di Leviathan che si desidera testare, si modifica la variabile e si va. Se necessario, puoi anche avere più variabili per le versioni testate più spesso, ad esempio "LEVIATHAN_LATEST", O "LEVIATHAN_PROBLEM_CHILD", ecc.

+0

Bene, questo è quello che intendevo quando ho parlato delle variabili di ambiente. Quindi, il problema qui è che ho ancora bisogno di cambiare il percorso di costruzione - se, ad esempio, volevo scaricare Test_10.0 e Test_scott, e averli compilati nello stesso spazio di lavoro, avrei bisogno di cambiare la variabile nel File .classpath in almeno uno dei due progetti di test. Idealmente, vorremmo evitare questo, perché in realtà non è migliore di quello che abbiamo in questo momento: dover cambiare Leviathan in Leviathan_scott o qualcosa di simile. – jwir3

+0

In realtà, una volta che la variabile si trova nel file .classpath, non la cambierai; almeno nel caso di $ LEVIATHAN per esempio. La build funziona con il valore della variabile classpath che hai impostato nel tuo spazio di lavoro. Puoi puntarlo su un target diverso senza dover modificare i file nel tuo progetto. –

+0

Beh, non proprio. Come risolverei il problema in cui ho Leviathan_10.0, Leviathan_Test_10, Leviathan_scott e Leviathan_test_scott nel mio spazio di lavoro, tutti aperti allo stesso tempo, e voglio che Leviathan_test_scott indichi Leviathan_scott e Leviathan_test_10 per puntare a Leviathan_10.0? – jwir3

2

Questo è un problema di gestione delle dipendenze e c'è un sacco di strumenti standard de-facto per aiutare! Suggerisco caldamente di utilizzare ANT con la gestione delle dipendenze Ivy's o utilizzare Maven (o qualsiasi altro strumento di generazione che abbia una gestione delle dipendenze).

Con uno di questi utilizzerei un repository artefatto come ad esempio Nexus o Artifactory, in modo da avere l'unica vera fonte per i propri artefatti interni.

In questo modo avrai sempre la versione canonica della libreria che desideri, quando lo desideri.

1

Se non si desidera utilizzare strumenti esterni per gestire le varie dipendenze del progetto, è possibile provare a passare ai singoli progetti Leviathan. Costruire proprietà del percorso, nella scheda Ordine ed Esporta e controllare le librerie necessarie per eseguire test. in questo modo non è necessario importare le librerie nel progetto di test e cambiando il progetto in prova si aggiornano automaticamente le librerie

+0

Hm ... sembra promettente. Quindi, stai dicendo che invece di importare tutte le librerie separatamente all'interno di un progetto di test, esportarle dal progetto originale di leviathan, tutto ciò che devo fare è importare il progetto leviathan nel progetto di test? – jwir3

+0

sì, questo potrebbe funzionare – pbanfi

Problemi correlati