Cosa c'è in un file .classpath / .project di Eclipse?

143

Di recente abbiamo avuto un problema con un progetto Eclipse per uno dei membri del nostro team. Tomcat non stava implementando JAR dell'applicazione.

Alla fine abbiamo notato che il .classpathfile Eclipse non era lo stesso dei membri del team in cui il progetto era OK. Abbiamo sostituito il .classpathfile con uno da un progetto che era OK e la distribuzione di Tomcat era completa.

Solo per curiosità e sapere cosa guardare in futuro se qualcosa non va, cosa c'è dentro i file .classpathe .project. Cosa posso aggiungere lì, cosa significa tutto ciò?

— eclissi totale
fonte

Il file .classpath è specifico di Java? Questa domanda sembra per lo più indipendente dal linguaggio, ma da questa risposta sembra che sia rilevante solo per Java.

— Casey Kuball,

correlate, stackoverflow.com/questions/13960556/...

— TT--

144

Eclipse è un ambiente di runtime per plugin. Praticamente tutto ciò che vedi in Eclipse è il risultato di plugin installati su Eclipse, piuttosto che Eclipse stesso.

Il .projectfile è gestito dalla piattaforma Eclipse di base e il suo obiettivo è descrivere il progetto da una vista Eclipse generica indipendente dal plug-in. Come si chiama il progetto? a quali altri progetti nell'area di lavoro fa riferimento? Quali sono i costruttori che vengono utilizzati per costruire il progetto? (ricorda, il concetto di "build" non riguarda specificamente i progetti Java, ma anche altri tipi di progetti)

Il .classpathfile è gestito dalla funzione JDT di Eclipse ( feature = set di plugin). JDT contiene più di questi "meta" file nel progetto (vedere la .settingsdirectory all'interno del progetto); il .classpathfile è solo uno di questi. In particolare, il .classpathfile contiene informazioni necessarie alla funzione JDT per compilare correttamente il progetto: le cartelle di origine del progetto (ovvero, cosa compilare); le cartelle di output (dove compilazione a ); e voci del percorso di classe (come altri progetti nell'area di lavoro, file JAR arbitrari sul file system e così via).

Copiare ciecamente tali file da una macchina all'altra può essere rischioso. Ad esempio, se i file JAR arbitrari vengono inseriti nel percorso di classe (ovvero, i file JAR che si trovano all'esterno dell'area di lavoro e a cui fanno riferimento la denominazione del percorso assoluto), il .classpathfile viene reso non portatile e deve essere modificato per essere portatile. Esistono alcune best practice che possono essere seguite per garantire la .classpathportabilità dei file.

— Isaac
fonte

58

Come estraneo a tutto ciò, tutto ciò si traduce in "Eclipse riesce in qualche modo a trasformare tutto ciò che riguarda la gestione dell'area di lavoro del progetto in un'arte nera imperscrutabile che è difficile da capire per chiunque".

— Warren P,

1

@Isaac - Per curiosità, nel caso in cui gestisca il mio progetto con gite Maven, nel senso che ho (per semplicità) la cartella "root" del repository (progetto) con una singola srccartella (contiene un semplice file "ciao mondo" .java) e il del progetto pox.xmldi file - quindi, se ho capito bene, non c'è bisogno (o forse anche necessariamente bisogno) per mantenere il: .project, .classpathe .settings/file / cartelle, nonché nel gitrepository (IE- aggiungerli al .gitignorefile di, per esempio)?

— Guy Avraham,

1

@GuyAvraham dipende da come lavori con Eclipse e, in particolare, da come inizializzi uno spazio di lavoro. Avvii Eclipse su un nuovo spazio di lavoro e quindi usi "importa progetti Maven esistenti"? in tal caso, allora hai ragione: nessuno di questi file è davvero necessario, come se m2eclipsene occuperà per te (o, almeno, è quello che dovrebbe fare).

— Isacco,

1

@buncis .projectnon dovrebbe essere in .gitignore. Per quanto riguarda .classpath- se si utilizza m2eclipsee l'area di lavoro è configurato per aggiornare i progetti Maven all'avvio, allora si dovrebbe essere OK con l'aggiunta .classpathdi .gitignore, ma non l'ho testato io stesso.

— Isacco,

1

@buncis ha appena corretto l'ultimo commento. Apparentemente, M2E oggi fa un ottimo lavoro nella configurazione di progetti. Di recente ho lavorato su una base di codice di circa 150 progetti Java di tutti i tipi. Ho rimosso .projecte .classpathda tutti loro e aggiunto a .gitignore. Tutto funziona bene e non ho bisogno di aggiornare continuamente questi file in Git troppo frequentemente.

— Isacco

37

.project

Quando viene creato un progetto nell'area di lavoro, viene generato automaticamente un file di descrizione del progetto che descrive il progetto. L'unico scopo di questo file è rendere il progetto auto-descrittivo, in modo che un progetto compresso o rilasciato su un server possa essere ricreato correttamente in un altro spazio di lavoro.

.classpath

Classpath specifica quali file di origine Java e file di risorse in un progetto sono considerati dal builder Java e specifica come trovare i tipi al di fuori del progetto. Il builder Java compila i file sorgente Java nella cartella di output e copia anche le risorse al suo interno.

— Rupesh Yadav
fonte

11

Il riferimento completo non è disponibile per i file menzionati, in quanto sono estensibili da vari plug-in.

Fondamentalmente, i file .project memorizzano le impostazioni del progetto, come il builder e le impostazioni della natura del progetto, mentre i file .classpath definiscono il percorso di classe da usare durante l'esecuzione. I file classpath contengono voci src e target che corrispondono alle cartelle nel progetto; le voci con sono usate per descrivere un tipo di voci "virtuali", come le librerie JVM o in caso di dipendenze dei plug-in di eclissi (le normali dipendenze dei progetti Java sono visualizzate in modo diverso, usando una voce speciale src).

— Zoltán Ujhelyi
fonte

3

Questa documentazione di eclissi contiene dettagli sui markup nel .projectfile: il file di descrizione del progetto

Descrive il .projectfile come:

Quando viene creato un progetto nell'area di lavoro, viene generato automaticamente un file di descrizione del progetto che descrive il progetto. Lo scopo di questo file è rendere il progetto auto-descrittivo, in modo che un progetto compresso o rilasciato su un server possa essere ricreato correttamente in un altro spazio di lavoro. Questo file si chiama sempre ".project"

— senpai
fonte