Devo mantenere i file di progetto come .project, .classpath, .settings di Eclipse, sotto il controllo della versione (es. Subversion, GitHub, CVS, Mercurial, ecc.)?
Risposte:
Vuoi mantenere nel controllo della versione tutti i file di impostazioni portatili ,
ovvero:
Qualsiasi file che non ha un percorso assoluto al suo interno.
Quello include:
Regola pratica per me:
devi essere in grado di caricare un progetto in un'area di lavoro e avere al suo interno tutto ciò di cui hai bisogno per configurarlo correttamente nel tuo IDE e andare avanti in pochi minuti.
Nessuna documentazione aggiuntiva, pagine wiki da leggere o cosa no.
Caricalo, configuralo, vai.
File .project e .classpath sì. Tuttavia, non manteniamo le nostre impostazioni IDE nel controllo della versione. Ci sono alcuni plugin che non fanno un buon lavoro di persistenza delle impostazioni e abbiamo scoperto che alcune impostazioni non erano molto portabili da una macchina di sviluppo all'altra. Quindi, abbiamo invece una pagina Wiki che evidenzia i passaggi necessari a uno sviluppatore per configurare il proprio IDE.
Questi sono quelli che considero file generati e come tali non li metto mai sotto il controllo della versione. Possono essere diversi da macchina a macchina e da sviluppatore a sviluppatore, ad esempio quando le persone hanno installato diversi plug-in Eclipse.
Invece, utilizzo uno strumento di compilazione (Maven) in grado di generare versioni iniziali di questi file quando effettui un nuovo checkout.
Sono combattuto tra due opzioni qui.
Da un lato, penso che tutti dovrebbero essere liberi di utilizzare il set di strumenti di sviluppo con cui sono più produttivi, purché tutti gli artefatti del sorgente siano archiviati nel controllo della versione e lo script di compilazione (ad esempio ANT o Maven) garantisca la conformità agli standard specificando esattamente quale JDK utilizzare, da quali versioni di quali librerie di terze parti dipendere, eseguendo controlli di stile (es.
D'altra parte, penso che così tante persone utilizzino gli stessi strumenti (ad esempio Eclipse) e spesso è molto meglio avere alcune cose standardizzate in fase di progettazione invece che in fase di compilazione - ad esempio Checkstyle è molto più utile come plugin Eclipse che come un'attività ANT o Maven - che è meglio standardizzare l'insieme di strumenti di sviluppo e un insieme comune di plugin.
Ho lavorato a un progetto in cui tutti usavano esattamente lo stesso JDK, la stessa versione di Maven, la stessa versione di Eclipse, lo stesso set di plugin Eclipse e gli stessi file di configurazione (es. Profili Checkstyle, regole di formattazione del codice ecc.). Tutti questi erano conservati nel controllo del codice sorgente: .project, .classpath e tutto nella cartella .settings. Ha reso la vita davvero facile durante le fasi iniziali del progetto, quando le persone modificavano continuamente le dipendenze o il processo di creazione. Ha anche aiutato immensamente quando si aggiungono nuovi principianti al progetto.
A conti fatti, penso che se non ci sono troppe possibilità di una guerra religiosa, dovresti standardizzare il set di base di strumenti di sviluppo e plugin e garantire la conformità della versione negli script di build (ad esempio specificando esplicitamente la versione Java). non pensare che ci siano molti vantaggi nell'archiviare JDK e l'installazione di Eclipse nel controllo del codice sorgente. Tutto il resto che non è un artefatto derivato, inclusi i file di progetto, la configurazione e le preferenze dei plug-in (in particolare il formattatore del codice e le regole di stile), dovrebbe andare nel controllo del codice sorgente.
PS Se usi Maven, c'è un argomento per dire che i file .project e .classpath sono artefatti derivati. Questo è vero solo se li generi ogni volta che fai una build e se non hai mai dovuto modificarli a mano (o cambiarli inavvertitamente cambiando alcune preferenze) dopo averli generati dal POM
No, perché ho solo i file di controllo della versione necessari per creare il software. Inoltre, i singoli sviluppatori possono avere le proprie impostazioni specifiche del progetto.
No, sono un utente Maven pesante e uso la Q per Eclipse plug-in che crea e mantiene aggiornati .project e .classpath. Per altre cose come le impostazioni per i plugin di solito mantengo una pagina README o Wiki su questo.
Anche quelli con cui ho lavorato preferiscono altri IDE usano semplicemente i plugin Maven per generare i file necessari per mantenere il loro IDE (e se stessi) felici.
Questa è tutta opinione, suppongo, ma le migliori pratiche nel corso degli anni indicano che i file specifici per un dato IDE non dovrebbero essere archiviati nel controllo del codice sorgente, a meno che l'intera organizzazione non sia standardizzata su un IDE e tu non abbia mai intenzione di cambiare.
Ad ogni modo, sicuramente non vuoi che le impostazioni dell'utente vengano memorizzate e .project può contenere impostazioni che sono davvero specifiche dello sviluppatore.
Consiglio di utilizzare qualcosa come Maven o Ant come sistema di compilazione standardizzato. Qualsiasi sviluppatore può ottenere un classpath configurato nel proprio IDE in pochi secondi.
Anche se generalmente sono d'accordo sull'approccio "non eseguire la versione dei file generati", abbiamo problemi con esso e dobbiamo tornare indietro.
Nota: sono anche interessato alla risposta di VonC , in particolare al punto "ottieni Eclipse in pochi minuti". Ma non è decisivo per noi.
Il nostro contesto è Eclipse + Maven, utilizzando il plug-in m2eclipse. Abbiamo un ambiente di sviluppo comune, con directory il più possibile comuni. Ma a volte capita che qualcuno provi un plug-in, o modifichi piccole cose nella configurazione, o importi un secondo spazio di lavoro per un ramo diverso ...
Il nostro problema è che la generazione di .project viene eseguita durante l'importazione di un progetto in Eclipse, ma non viene aggiornata in tutti i casi in seguito . È triste e probabilmente non permanente poiché il plug-in m2eclipse migliorerà, ma al momento è vero. Quindi finiamo per avere configurazioni diverse. Quello che abbiamo avuto oggi era questo: diverse nature sono state aggiunte a molti progetti su alcune macchine, che poi si sono comportate in modo molto diverso :-(
L'unica soluzione che vediamo è la versione del file .project (per evitare rischi, faremo lo stesso per .classpath e .settings). In questo modo, quando uno sviluppatore cambia il suo pom, i file locali vengono aggiornati utilizzando m2eclipse, tutti vengono impegnati insieme e altri sviluppatori vedranno tutte le modifiche.
Nota: nel nostro caso, utilizziamo nomi di file relativi, quindi non abbiamo problemi a condividere quei file.
Quindi, per rispondere alla tua domanda, dico di sì, salva quei file.
Mi è anche piaciuto:
Sembra che questi file di progetto possano cambiare nel tempo mentre lavori su un progetto, quindi sì, li metto sotto il controllo della versione.
Usiamo IntelliJ IDEA e manteniamo le versioni ".sample" dei file di progetto (.ipr) e del modulo (.iml) sotto il controllo della versione.
La cosa un po 'più grande qui è la condivisione e il riutilizzo delle versioni, IMHO. Ma se hai intenzione di condividere queste configurazioni, quale posto migliore per metterle se non il repository, proprio accanto a tutto il resto.
Alcuni vantaggi dei file di progetto condivisi e con versione:
Notare che in IDEA questi file contengono configurazioni come: quali sono le directory "source" e "test source"; tutto ciò che riguarda le dipendenze esterne (dove si trovano i jar della libreria, nonché le relative fonti o javadoc); opzioni di compilazione, ecc. Questa è roba che non varia da sviluppatore a sviluppatore (non sono assolutamente d' accordo con questo ). IDEA memorizza più impostazioni IDE personali altrove, così come qualsiasi configurazione di plugin. (Non conosco Eclipse così bene; questo potrebbe o non potrebbe essere abbastanza diverso.)
Sono d'accordo con questa risposta che dice:
Devi essere in grado di caricare un progetto in uno spazio di lavoro e avere al suo interno tutto ciò di cui hai bisogno per configurarlo correttamente nel tuo IDE e andare avanti in pochi minuti. [...] Caricalo, configuralo, vai.
E lo abbiamo così, grazie ai file di progetto con versione.