Progetto Java: il file .classpath .project deve essere inserito nel repository?

Question

Devo controllare i file .project e .classpath?

Il mio amico mi ha detto che dovrei controllare solo i file .java e il file build.xml per garantire la portabilità. ".classpath ti causerà molto meno portabilità su un ambiente diverso. .project è interamente la tua impostazione eclissi locale"

Sono d'accordo con lui, ma parzialmente.

- Non check-in file di .project farà il mio sviluppo meno efficiente (non posso semplicemente "importare" un codice di progetto da una directory)

- Non check-in .classpath file sembra OK per me (?) se il mio build.xml è scritto attentamente.

Qualcuno vuole condividere la sua esperienza qui?

Answer 1

Non c'è niente di sbagliato con il check-in .project e .classpath. Lo farei se il tuo build.xml non è in grado di creare entrambi i file per te. Come hai detto, è scomodo perdere questi file quando si tenta di creare un nuovo spazio di lavoro di Eclipse.

Prima di effettuare il check-in .classpath, è necessario accertarsi che non vi siano percorsi assoluti. Convertilo in uno relativo con un editor di testo.

Modifica: Oppure, meglio ancora, utilizzare le variabili del classpath eclipse nei percorsi altrimenti assoluti, come commentato @ taylor-leese.

Answer 2

Una cosa che vorrei fare attenzione con il check-in file .classpath è assicurarsi di non fare riferimento ai file al di fuori del progetto. Eclipse memorizza la posizione di questi file con un percorso file completo e dovresti assicurarti che altri sviluppatori abbiano quei file esattamente nella stessa posizione.

Answer 3

Non check-in file di .project sarà fare il mio sviluppo meno efficiente (I non può semplicemente "importare" un codice di progetto da una directory)

per questo problema, è possibile scegliere per creare un nuovo progetto e importare l'origine esistente.

un problema con file specifici IDE come .project è che altri sviluppatori potrebbero voler utilizzare un altro IDE per sviluppare il progetto, in modo che possano aggiungere un altro tipo di file di progetto. questo renderà il tuo repository disordinato.

Answer 4

Non c'è alcun problema di archiviazione dei file .classpath e .project nel repository. Aiuterà gli sviluppatori che usano Eclipse per andare più veloce.

Avviso: verificare che il file .classpath faccia riferimento solo a risorse utente che sono state verificate nel repository con il progetto o che possono essere ottenute automaticamente (ad esempio artefatti maven).

Answer 5

Preferirei controllare .project e .classpath.

Questo sarebbe utile quando questo progetto è condiviso da più sviluppatori. Diventa facile e veloce per configurare l'ambiente di sviluppo. semplicemente importandolo come progetto esistente su qualsiasi sistema utilizzando eclipse.

Qui è necessario prestare attenzione solo se i percorsi di classe sono relativi al progetto.

Answer 6

In realtà non conosco i file delle preferenze di eclissi, ma con IntelliJ questi file sono agnostici del sistema operativo, il che significa che non rovinerà la portabilità. A meno che non si definiscano le librerie con un percorso completo per il proprio sistema (Sarebbe piuttosto pericoloso/stupido).

Quando si condividono le preferenze, si è sicuri che tutti lavoreranno con le stesse condizioni sul progetto (configurazione dei plug-in, codifica, profili [per intelliJ]) che possono davvero essere una buona cosa.

Non mi dà fastidio quando alcuni file Eclipse sono qui, e penso che non dovrebbe/non infastidisce gli altri sviluppatori quando alcuni file nascosti si trovano solo lì.

Answer 7

Effettuiamo il check in .project e .classpath. Con ProjectSet questo ci consente di controllare aree di lavoro complesse con un singolo "Import Team ProjectSet"

Answer 8

La domanda chiave con tutti questi file è "Possono essere riprodotti automaticamente?" In caso contrario, controllali nel controllo del codice sorgente.

In questo caso, direi "sì", a meno che non si usi Maven, che ha m2eclipse e il plug-in di eclipse per generarli per voi.

Answer 9

Per i miei 2 centesimi, lo classificherei come una cattiva pratica. I progetti non dovrebbero essere legati a un IDE e, soprattutto, non dovrebbero essere legati a una versione specifica di un IDE.

Il controllo dei file di configurazione Eclipse potrebbe funzionare bene per progetti più semplici ea breve termine. Per i progetti più grandi che sono stati sviluppati nell'arco di diversi anni, questo generalmente causa più problemi, poiché le versioni IDE cambiano e i file di configurazione del progetto no. Immagina di controllare un ramo di 2 anni con i file di configurazione di Eclipse 2.0 in Eclipse 4.3 con alcune librerie personalizzate e l'integrazione di m2e ... Non è affatto divertente ...

Answer 10

Ho spesso domande simili e più generali. Il problema è essenzialmente:

• quali file sono io commettere per me ?
• quali file sto eseguendo per altri?
• → Come si combinano entrambi gli obiettivi di "versionning"?

offrii discutere di questo there, quindi è possibile trovare maggiori dettagli in merito al problema, insieme a soluzioni interessanti :)

---

Quello che mi piace di più è l'uso di git submodule: mantenere i file .projectecc. in un repo di commit privato. E rendi la tua produzione finale, pura, essenziale src in un nugget ordinato submodule: un repo pubblico.

project/ # root module 
| .git # private repo 
| .project 
| .classpath 
| momsNumber.txt 
+---src/  # submodule 
| | .git # public repo 
| | main.java 
| +---package/ 
| | | Etc.java 

---

See there anyway.