2010-04-23 17 views
6

esempio:
Per la registrazione, il mio codice utilizza log4j. ma altri vasi da cui dipende il mio codice, usa invece slf4j. Quindi entrambi i vasi devono essere nel percorso di costruzione. Sfortunatamente, è possibile che il mio codice utilizzi direttamente (dipende da) slf4j ora, sia da context-assist, sia da altre modifiche degli sviluppatori. Vorrei che qualsiasi utilizzo di slf4j fosse visualizzato come un errore, ma durante l'esecuzione la mia applicazione (e i test) saranno comunque necessari nel classpath.eclipse, un classpath per la compilazione, un altro per l'avvio

spiegazione:
Mi piacerebbe scoprire se questo è possibile in eclissi. Questo scenario accade spesso per me. Avrò un grande progetto, che usa un sacco di librerie di terze parti. E naturalmente quei barattoli di terze parti hanno le loro dipendenze pure. Quindi devo includere tutte le dipendenze nel classpath ("percorso di compilazione" in eclipse) per l'applicazione e i suoi test per compilare ed eseguire (da dentro eclipse).

Ma non voglio il codice per utilizzare tutti quei barattoli, solo le poche dipendenze dirette che ho deciso su me stesso. Quindi, se il mio codice utilizza accidentalmente una dipendenza di una dipendenza, voglio che venga visualizzato come errore di compilazione. Idealmente, come classe non trovata, ma qualsiasi errore farebbe.

So che posso configurare manualmente il classpath quando si esegue all'esterno di eclipse e anche all'interno di eclipse posso modificare il classpath per una classe specifica che sto utilizzando (nelle configurazioni di esecuzione), ma questo non è gestibile se si esegue molto dei singoli casi di test o hanno un sacco di classi main().

risposta

0

Sembra che sarebbe meglio essere gestito con Maven, integrato in eclissi con m2eclipse.

In questo modo, è possibile eseguire solo parte del ciclo di vita di generazione di Maven ed è possibile gestire un insieme separato di dipendenze per passaggi di generazione.

0

Nella mia esperienza aiuta ad essere più resrictive, ho fatto la squadra compilazione (carta) forme perché è necessaria questa barattolo e quello di licenza ...

e hanno fatto piuttosto tipo in poche righe di codice invece di trascinare lungo 20 vasi per aprire un file utilizzando solo una riga di codice o un'altra "funzionalità" di fantasia.

L'utilizzo di Maven potrebbe aiutare per un po ', ma quando per la prima volta si vedono barattoli con nomi come night-build o istantanea, si saprà di essere nel baratro dell'inferno.

conclusione: Scegli dipendenze ben

2

Sembra che il progetto abbia abbastanza relazioni di dipendenza che è possibile prendere in considerazione strutturandolo con bundle OSGi (plug-in). Ogni bundle ha il proprio classloader e può specificare quali pacchetti (e quali intervalli di versione, ecc.) Dipende, quali pacchetti esporta, se esporta nuovamente roba dalle sue dipendenze, ecc.

Eclipse stesso è strutturato su plug-in e frammenti di Eclipse, che sono solo bundle OSGi con un piccolo bit opzionale di cablaggio aggiuntivo Eclipse (plugin.xml, che viene utilizzato per dichiarare "punti di estensione" ed "estensioni" di Eclipse). Eclipse ha quindi strumenti abbastanza buoni per la creazione e la gestione di pacchetti integrati (tramite l'ambiente di sviluppo plug-in). Molto di ciò che si trova là fuori può portare a confondere "bundle OSGi" con "plug-in che estende l'IDE di Eclipse", ma i due concetti sono abbastanza separabili.

Gli strumenti Eclipse distinguono in modo piuttosto chiaro (e talvolta fastidioso, ma nel modo "medicina utile") tra i bundle nell'ambiente di compilazione rispetto ai pacchetti che include una particolare configurazione di esecuzione.

Dopo alcuni anni di permanenza nella terra di OSGi, il "percorso di classe piatto" predefinito di Java si sente strano e persino spezzato per me, soprattutto perché (come hai sperimentato) getta tutti i JAR in un'arena gigante e speranze possono risolvere le cose. L'ambiente OSGi mi dà molto più controllo sulle relazioni di dipendenza, e anche un "effetto collaterale" richiede naturalmente un chiarimento di tali relazioni. Tra queste chiare dichiarazioni e la loro applicazione da parte degli strumenti, la struttura del progetto è più ovvia per tutti i membri del team.

se il mio codice utilizza accidentalmente una dipendenza di una dipendenza, voglio che venga visualizzato come errore di compilazione. Idealmente, come classe non trovata, ma qualsiasi errore farebbe.

Inserire il codice in un plug-in, le dipendenze dirette in altri plug-in, le loro dipendenze in altri plug-in, ecc. E dichiarare le dipendenze di ogni plug-in. Eclipse farà immediatamente esattamente quello che vuoi. Non ti verrà offerto il contenuto delle dipendenze 'dipendenze' in autocompletes; otterrai scarabocchi rossi e creerai errori; ecc.

+0

un'altra buona risposta, peccato che ne possa scegliere solo uno. – DragonFax

0

L'uso del contenitore slf4j-over-log4j sarebbe utile? Ciò consente di utilizzare slf4j con la registrazione effettiva andando a log4j.

Problemi correlati