.classpath e .project - check in controllo di versione o no?

Question

Sto eseguendo un progetto Java open source che consiste di più moduli in un albero di dipendenze. Tutti questi moduli sono sottodirectory in un repository di subversion. Per i neofiti del nostro progetto, è molto lavoro impostare manualmente tutto in eclissi.

Non tutti i nostri sviluppatori utilizzano eclipse. Ciononostante, stiamo valutando di controllare i file .classpath e .project per aiutare i nuovi arrivati ​​a iniziare. E 'questa una buona idea? O questo porterebbe a conflitti costanti in quei file? C'è un modo alternativo per rendere il progetto facile da configurare su Eclipse?

Answer 1

definitivamente sì, come ho detto in "Do you keep your project files under version control?"

"Caricalo, impostalo, vai."

Ma ... questo è in realtà vero solo per le impostazioni Eclipse3.5 recenti, in cui costruire percorsi supporto percorsi relativi:

---

E Eclipse3.6 sarebbe meglio , in quanto supporta percorsi relativi per le variabili di percorso in Linked Resources:

(dal 3.6M5)

Answer 2

Decisamente no - è generalmente un'idea terribile distribuire i file di progetto tramite subversion. Soprattutto perché qualcuno potrebbe modificarli in un modo strano. Una buona pagina nella documentazione del progetto è un'idea molto migliore. Il nostro progetto ha anche molti moduli e una configurazione complessa. Abbiamo creato una pagina di confluenza che descrive come iniziare con il progetto su ciascun IDE populer: IntelliJ, Eclipse, NetBeans. Un file README in Subversion contiene le stesse informazioni.

Answer 3

Vorrei controllare i file in essi contenuti per rendere l'avvio per i nuovi utenti il ​​più semplice possibile. Nel migliore dei casi l'utente dovrebbe verificare il progetto e dovrebbe essere in grado di eseguirlo senza ulteriori conoscenze. Per questi file le regole sono le stesse degli altri file nel progetto: gestirli con cura. Non si dovrebbero posizionare percorsi assoluti nel codice sorgente, ne più ci si dovrebbe nei file di configurazione.

Se i file vengono archiviati in modo che il progetto venga eseguito da zero, non ci dovrebbero essere molte forze per modificarli.

Answer 4

Si consiglia di controllare i file in sovversione SE essi non contengono percorsi assoluti e altri dati che li legherebbero direttamente all'ambiente di un singolo sviluppatore.

Se i file contengono percorsi assoluti e simili, un README sarebbe una scelta migliore.

Answer 5

Sì, è necessario verificarlo, ma assicurarsi di documentare eventuali dipendenze del percorso ed evitare percorsi assoluti, se possibile.

Se non si effettua il check-in, chiunque effettui il check out del progetto dovrà ricreare tutte quelle impostazioni, che sono fastidiose e potenzialmente soggette a errori.

Alcune configurazioni complesse possono essere meglio gestite da uno script per generare questi file, ma di solito è meglio controllarli appena in.

Answer 6

io voto no, ma questo è perché vorrei generalmente generare questi file da Maven

Answer 7

Nella mia esperienza, escludendo i casi limitati in cui sono coinvolti impostazioni puramente locali, tutto dovrebbe essere in controllo del codice sorgente. La legge del controllo della fonte è che dovrebbe essere previsto che tutto ciò che viene spinto funzioni da coloro che tirano fuori. Purtroppo, spesso causa eclissi cose come questo per essere in .classpath:

<classpathentry kind="con" 
     path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/> 

Quindi sul mio Mac questo funziona, e forse qualcuno su un Mac ha lo stesso JRE, ma questo non funzionerà per chiunque altro.

Inoltre, non c'è un modo semplice per aggirare questo. Eclipse lo aggiungerà sempre. VOGLIO avere il file .classpath lì, perché ci sono alcuni JAR di terze parti nella nostra cartella lib in cui ci interessa il versioning, quindi li lasciamo lì così i nuovi sviluppatori non devono ottenerli . Ci stiamo spostando verso un sistema gestito, ma abbiamo ancora gestito le dipendenze + non gestite. Ciò significa che tutti gli sviluppatori devono solo assicurarsi che due directory siano nel loro .classpath s. Ma è meglio che dover riparare il tuo JRE ogni volta che si tira e avere un cambiamento nel tuo percorso .Class ogni volta che si commette.

Tuttavia, Eclipse offre alcune altre cose carine. Il file .project di solito sarà lo stesso in tutte le istanze, quindi includilo. Ma la cosa migliore del controllo del codice sorgente per eclipse sono le impostazioni Esegui configurazioni. Sotto la scheda "Comune" nella finestra di dialogo Esegui configurazioni, salva le configurazioni in modo che appaiano per i tuoi colleghi sotto gli elenchi dei preferiti per Debug ed Esegui. Per me, un gruppo di file .launch si trova nella directory .settings, quindi tutti li possiamo usare.

Allora io dico: .settings elenco va in controllo del codice sorgente per il file di configurazione di lancio (tranne .prefs *)

.classpath rimane fuori

.project va in