.classpath dan .project - periksa ke kontrol versi atau tidak?

89

Saya menjalankan proyek java open source yang terdiri dari beberapa modul dalam pohon dependensi. Semua modul tersebut adalah subdirektori dalam repositori subversi. Untuk pendatang baru di proyek kami, banyak pekerjaan untuk mengatur semua itu secara manual di eclipse.

Tidak semua developer kami menggunakan eclipse. Namun demikian, kami mempertimbangkan untuk hanya memeriksa file .classpath dan .project untuk membantu pendatang baru memulai. Apakah ini ide yang bagus? Atau akankah itu menyebabkan konflik konstan dalam file-file itu? Adakah cara alternatif untuk membuat proyek mudah disiapkan di eclipse?

eclipse version-control ide amarillion
sumber
1
kemungkinan duplikat dari Haruskah saya menyimpan file proyek saya di bawah kendali versi?
Steve Chambers

Jawaban:

66

Jelas ya, seperti yang saya katakan di " Apakah Anda menyimpan file proyek Anda di bawah kontrol versi? "

"Muat, siapkan, pergi."

Tetapi ... ini sebenarnya hanya berlaku untuk setelan Eclipse3.5 terbaru, di mana jalur build mendukung jalur relatif :

Jalur build mendukung jalur relatif

Dan Eclipse3.6 akan lebih baik, karena mendukung jalur relatif untuk variabel jalur di Linked Resources:

variabel jalur dengan jalur relatif
(sejak 3.6M5)

VonC
sumber
2
Wow, saya tidak tahu mereka menambahkan ini ... Akan menyelamatkan kita dari kesedihan
Uri
Sepertinya gambar yang terkait dengan jawaban ini off-line.
vkraemer
1
@vkraemer: benar. Saya sekarang telah memulihkan dua gambar itu, yang pertama berasal dari archive.eclipse.org/eclipse/downloads/drops/R-3.5-200906111540/… dan yang kedua dari download.itemis.com/mirror/eclipse/R-3.6 -201006080911./… .
VonC
17

Jelas tidak - umumnya ide yang buruk untuk mendistribusikan file proyek melalui subversi. Terutama karena seseorang mungkin memodifikasinya dengan cara yang aneh. Halaman yang bagus dalam dokumentasi proyek adalah ide yang jauh lebih baik. Proyek kami juga memiliki banyak modul dan pengaturan yang kompleks. Kami telah menyiapkan halaman pertemuan yang menjelaskan cara memulai proyek di setiap IDE populer - IntelliJ, Eclipse, NetBeans. File README di Subversion berisi info yang sama.

Bozhidar Batsov
sumber
32
Saya tidak setuju. Dari pengalaman saya, ada baiknya untuk memeriksa file-file ini agar proses pembayarannya semudah mungkin. Seseorang mungkin mengubahnya dengan cara yang aneh? Seseorang mungkin mengubah kode Anda dengan cara yang aneh ...
Arne Deutsch
Arne, Anda harus membuat jawaban, bukan komentar.
amarillion
5
File proyek untuk setiap IDE sebenarnya bukan bagian dari proyek apa pun - jika Anda ingin mendistribusikannya - silakan lampirkan ke artikel yang saya sebutkan. Umumnya setiap orang dalam tim dapat memodifikasi file dalam repo, tetapi tidak semua orang dapat melampirkan file baru ke node dokumentasi penting, dll. Sangat mudah bagi seseorang untuk lupa mengabaikan classpath dan file proyek dan menjalankannya pada saat yang tidak semestinya. Bahkan jika Anda menyimpannya dalam subversi - Anda pasti harus menyimpannya di suatu tempat di samping ...
Bozhidar Batsov
8
-1, sangat tidak setuju. Pengaturan proyek adalah bagian penting dari pekerjaan sehari-hari dengan sebuah proyek. Kerugian dari memeriksa pengaturan yang salah secara tidak sengaja jauh lebih kecil daripada keuntungan dari selalu memperbarui semua orang secara otomatis. Bagaimanapun, Anda selalu dapat dengan mudah kembali ke versi sebelumnya.
Michael Borgwardt
7
Setiap orang berhak mendapatkan pendapat. Faktanya, saya tidak pernah membuat proyek yang mengandalkan sistem proyek Eclipse (atau IDE lainnya) sejak awal ... Maven adalah alat pemahaman proyek utama dan membuat pengaturan khusus IDE menjadi usang. Btw waktu untuk menyadari bahwa ada yang salah dengan pengaturan saat ini dan kembali ke revisi sebelumnya sepertinya tidak akan berbeda dari waktu untuk menyesuaikan sendiri pengaturan baru. Setidaknya di perusahaan saya, semua orang di tim diberi tahu melalui email jika diperlukan intervensi pengguna setelah perubahan yang lebih besar.
Bozhidar Batsov
10

Saya memilih tidak, tapi itu karena saya biasanya akan menghasilkan file-file ini dari maven

Goibniu
sumber
m2e melakukan sebagian besar tetapi tidak semuanya untuk Anda
Junchen Liu
6

Dalam pengalaman saya, tidak termasuk kasus terbatas di mana pengaturan lokal murni terlibat, semuanya harus dalam kendali sumber. Hukum pengendalian sumber adalah bahwa segala sesuatu yang didorong masuk harus diharapkan bekerja oleh mereka yang menarik diri. Sayangnya, gerhana seringkali menyebabkan hal-hal seperti ini menjadi .classpath:

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

Jadi di Mac saya ini berfungsi, dan mungkin seseorang di Mac memiliki JRE yang sama, tetapi ini tidak akan berfungsi untuk orang lain.

Juga, tidak ada cara mudah untuk mengatasi ini. Eclipse akan selalu menambahkannya. Saya INGIN memiliki file .classpath di sana, karena ada beberapa JAR pihak ke-3 di folder lib kami di mana kami peduli tentang pembuatan versi, jadi kami membiarkannya di sana sehingga pengembang baru tidak perlu mendapatkannya . Kami pindah ke sistem terkelola, tetapi masih memiliki dependensi terkelola + tak terkelola yang diperiksa. Ini berarti semua pengembang hanya perlu memastikan dua direktori ada di direktori mereka .classpath. Tetapi lebih baik daripada harus memperbaiki JRE Anda setiap kali Anda menarik dan memiliki perubahan di .classpath Anda setiap kali Anda berkomitmen.

Eclipse melakukan beberapa hal baik lainnya untuk Anda. File .project biasanya akan sama di semua instance, jadi sertakan itu. Tetapi hal terbaik tentang kontrol sumber untuk gerhana adalah pengaturan Konfigurasi Jalankan. Di bawah tab "Umum" di dialog Jalankan Konfigurasi, simpan konfigurasi agar muncul untuk kolega Anda di bawah daftar favorit untuk Debug dan Jalankan. Bagi saya, banyak .launchfile masuk ke .settingsdirektori, jadi kita semua bisa menggunakannya.

Jadi saya katakan: .settingsdirektori masuk ke kontrol sumber untuk konfigurasi peluncuran (kecuali * .prefs)

.classpath tetap keluar

.project masuk.

Zak Patterson
sumber
Apakah ini kasusnya bahkan saat menggunakan lingkungan eksekusi untuk JRE / JVM?
Mr_and_Mrs_D
5

Saya akan memeriksa file-file ini untuk memulai bagi pengguna baru semudah mungkin. Paling baik pengguna harus memeriksa proyek dan harus dapat menjalankannya tanpa pengetahuan tambahan. Untuk file ini aturannya sama dengan file lainnya dalam proyek: tangani dengan hati-hati. Anda tidak boleh menempatkan jalur absolut di kode sumber, selain itu Anda harus di file konfigurasi.

Jika file diperiksa sedemikian rupa sehingga proyek berjalan dari awal, seharusnya tidak ada banyak kekuatan untuk mengubahnya.

Arne Deutsch
sumber
5

Saya akan merekomendasikan agar Anda memeriksa file ke dalam subversi JIKA mereka tidak berisi jalur absolut dan data lain yang akan mengikatnya secara langsung ke lingkungan pengembang tunggal.

Jika file memang berisi path absolut dan sejenisnya, README akan menjadi pilihan yang lebih baik.

vkraemer.dll
sumber
2

Ya, pastikan Anda memeriksanya, tetapi pastikan Anda mendokumentasikan dependensi jalur apa pun dan menghindari jalur absolut jika memungkinkan.

Jika Anda tidak memeriksanya, maka siapa pun yang memeriksa proyek perlu membuat ulang semua pengaturan tersebut, yang mengganggu dan berpotensi rawan kesalahan.

Beberapa pengaturan kompleks mungkin lebih baik ditangani oleh skrip untuk menghasilkan file-file ini, tetapi biasanya lebih baik untuk hanya memeriksanya.

Christopher Barber
sumber