Eclipse'in .project, .classpath, .settings gibi proje dosyalarını sürüm kontrolü altında tutmalı mıyım (örn. Subversion, GitHub, CVS, Mercurial, vb.)?
Yanıtlar:
Herhangi bir taşınabilir ayar dosyasını sürüm kontrolünde tutmak istiyorsunuz ,
yani:
Mutlak yolu olmayan herhangi bir dosya.
Şunları içerir:
Benim için temel kural:
Bir projeyi bir çalışma alanına yükleyebilmeli ve IDE'nizde doğru şekilde kurmak ve dakikalar içinde çalışmaya başlamak için ihtiyacınız olan her şeye sahip olmalısınız.
Ek belge, okunacak wiki sayfası yok.
Yükleyin, kurun, gidin.
.project ve .classpath dosyaları evet. Ancak IDE ayarlarımızı sürüm kontrolünde tutmuyoruz. Kalıcı ayarlarda iyi bir iş çıkarmayan bazı eklentiler var ve bazı ayarların bir dev makineden diğerine çok taşınabilir olmadığını gördük. Bunun yerine, bir geliştiricinin IDE'sini kurması için gereken adımları vurgulayan bir Wiki sayfamız var.
Bunlar, oluşturulmuş dosyalar olarak düşündüğüm şeylerdir ve bu nedenle onları asla sürüm kontrolü altına koymam. Makineden makineye ve geliştiriciden geliştiriciye farklı olabilirler, örneğin insanlar farklı Eclipse eklentilerine sahip olduğunda.
Bunun yerine, yeni bir teslim aldığınızda bu dosyaların ilk sürümlerini oluşturabilen bir derleme aracı (Maven) kullanıyorum.
Burada iki seçenek arasında kaldım.
Bir yandan, tüm kaynak yapıları sürüm kontrolünde depolandığı ve derleme komut dosyasının (örneğin ANT veya Maven) standartlara uyumu sağladığı sürece, herkesin en üretken oldukları geliştirme araçlarını kullanmakta özgür olması gerektiğini düşünüyorum. tam olarak hangi JDK'nın kullanılacağını, hangi üçüncü taraf kitaplıklarının hangi sürümlere bağlı olacağını, stil kontrollerinin çalıştırılmasını (örneğin kontrol stili) ve birim testlerinin çalıştırılması vb.
Öte yandan, pek çok insanın aynı araçları kullandığını düşünüyorum (örn. Eclipse) ve genellikle bazı şeylerin geliştirme zamanı yerine tasarım zamanında standartlaştırılması çok daha iyidir - örneğin Checkstyle bir Eclipse eklentisi olarak olduğundan çok daha kullanışlıdır. bir ANT veya Maven görevi - geliştirme araçları seti ve ortak bir eklenti seti üzerinde standartlaştırmanın daha iyi olduğu.
Herkesin tam olarak aynı JDK'yı, Maven'in aynı sürümünü, Eclipse'in aynı sürümünü, aynı Eclipse eklentileri setini ve aynı yapılandırma dosyalarını (örn. Checkstyle profilleri, kod biçimlendirici kuralları vb.) Kullandığı bir proje üzerinde çalıştım. Bunların tümü kaynak kontrolünde tutuldu - .project, .classpath ve .settings klasöründeki her şey. İnsanların sürekli olarak bağımlılıkları veya inşa sürecini değiştirdiği projenin ilk aşamalarında hayatı gerçekten kolaylaştırdı. Projeye yeni başlayanlar eklerken de çok yardımcı oldu.
Öte yandan, dini bir savaş için çok fazla şansı yoksa, temel geliştirme araçları ve eklentileri setini standartlaştırmanız ve derleme komut dosyalarınızda sürüm uyumluluğunu sağlamanız gerektiğini düşünüyorum (örneğin, Java sürümünü açıkça belirterek). JDK ve Eclipse kurulumunu kaynak kontrolünde depolamanın pek bir faydası olduğunu düşünmeyin. Türetilmiş bir yapı olmayan her şey - proje dosyalarınız, konfigürasyonunuz ve eklenti tercihleriniz (özellikle kod formatlayıcı ve stil kuralları) dahil - kaynak kontrolüne gitmelidir.
PS Maven kullanıyorsanız, .project ve .classpath dosyalarının türetilmiş yapılar olduğunu söyleyen bir argüman vardır. Bu, yalnızca bir yapı oluşturduğunuzda bunları oluşturuyorsanız ve bunları POM'dan oluşturduktan sonra elle değiştirmek zorunda kalmadıysanız (veya bazı tercihleri değiştirerek yanlışlıkla değiştirmediyseniz) doğrudur.
Hayır, çünkü sadece yazılımı oluşturmak için gerekli olan kontrol dosyalarının sürümünü kullanıyorum. Ayrıca, bireysel geliştiricilerin kendi projeye özel ayarları olabilir.
Hayır, yoğun bir Maven kullanıcısıyım ve .project ve .classpath'i oluşturan ve güncel tutan Q for Eclipse eklentisini kullanıyorum. Eklenti ayarları gibi diğer şeyler için genellikle bununla ilgili bir README veya Wiki sayfası hazırlarım.
Ayrıca diğer IDE'leri tercih eden birlikte çalıştığım kişiler, IDE'lerini (ve kendilerini) mutlu etmek için gereken dosyaları oluşturmak için sadece Maven eklentilerini kullanıyor.
Sanırım bu tamamen fikirdir - ancak yıllar içindeki en iyi uygulamalar, kuruluşunuzun tamamı tek bir IDE'de standartlaştırılmadıkça ve hiçbir zaman geçiş yapma niyetiniz olmadıkça, belirli bir IDE'ye özgü dosyaların kaynak kontrolünde depolanmaması gerektiğini gösterir.
Her iki durumda da, kesinlikle kullanıcı ayarlarının saklanmasını istemezsiniz - ve .project gerçekten geliştiriciye özel ayarlar içerebilir.
Standart bir yapı sistemi olarak Maven veya Ant gibi bir şey kullanmanızı öneririm. Herhangi bir geliştirici, IDE'lerinde yapılandırılmış bir sınıf yolunu birkaç saniye içinde alabilir.
Genel olarak "oluşturulan dosyaların sürümlerini çıkarma" yaklaşımını kabul etsem de, bununla ilgili sorunlarımız var ve geri dönmemiz gerekiyor.
Not: VonC'nin yanıtı , özellikle "Eclipse'i dakikalar içinde ayağa kaldır" noktasıyla da ilgileniyorum . Ama bizim için belirleyici değil.
Bağlamımız m2eclipse eklentisini kullanan Eclipse + Maven'dir. Mümkün olduğunca ortak dizinlerle ortak bir geliştirme ortamına sahibiz. Ancak bazen birileri bir eklenti dener veya yapılandırmadaki küçük şeyleri değiştirir veya farklı bir şube için ikinci bir çalışma alanını içe aktarır ...
Bizim sorunumuz, .project'in oluşturulmasının Eclipse'de bir proje içe aktarılırken yapılması, ancak daha sonra her durumda güncellenmemesidir . Bu üzücü ve m2eclipse eklentisi gelişeceği için muhtemelen kalıcı değil, ama şu anda doğru. Böylece farklı konfigürasyonlara sahip oluyoruz. Bugün sahip olduğumuz şey şuydu: Bazı makinelerde birçok projeye birkaç doğa eklenmiş ve bunlar daha sonra çok farklı davranmıştır :-(
Gördüğümüz tek çözüm, .project dosyasını sürümlemektir (riskleri önlemek için, aynısını .classpath ve .settings için de yapacağız). Bu şekilde, bir geliştirici pom'unu değiştirdiğinde, yerel dosyalar m2eclipse kullanılarak güncellenir, hepsi birlikte işlenir ve diğer geliştiriciler tüm değişiklikleri görür.
Not: Bizim durumumuzda göreceli dosya adları kullanıyoruz, bu nedenle bu dosyaları paylaşmakta sorun yaşamıyoruz.
Yani, sorunuzu cevaplamak için, evet diyorum, bu dosyaları işleyin.
Ben de begendim:
Bir proje üzerinde çalışırken bu proje dosyaları zamanla değişebilir gibi görünüyor, bu yüzden evet, onları sürüm kontrolü altına alıyorum.
IntelliJ IDEA kullanıyoruz ve proje (.ipr) ve modül (.iml) dosyalarının '.sample' sürümlerini sürüm kontrolü altında tutuyoruz.
Burada biraz daha önemli olan şey paylaşmak ve yeniden kullanmaktırIMHO, sürümlemeden . Ama bu konfigürasyonları paylaşacaksanız, onları depodan daha iyi bir yer, diğer her şeyin hemen yanında.
Paylaşılan ve sürümü belirlenmiş proje dosyalarının bazı avantajları:
IDEA'da bu dosyaların aşağıdaki gibi yapılandırmaları içerdiğini unutmayın: "kaynak" ve "test kaynağı" dizinleri nelerdir; dış bağımlılıklar hakkında her şey (kitaplık kavanozlarının yanı sıra ilgili kaynaklar veya javadoc'ların bulunduğu yerler); oluşturma seçenekleri, vb Bu vermez şeyler değil geliştirici geliştirici değişir (I katılmıyorum bu oldukça kuvvetli). IDEA, herhangi bir eklenti yapılandırmasının yanı sıra başka yerlerde daha fazla kişisel IDE ayarı saklar. (Eclipse'i o kadar iyi bilmiyorum; bu oldukça farklı olabilir veya olmayabilir.)
Bu cevaba katılıyorum :
Bir projeyi bir çalışma alanına yükleyebilmeli ve IDE'nizde doğru şekilde kurmak ve dakikalar içinde çalışmaya başlamak için ihtiyacınız olan her şeye sahip olmalısınız. [...] Yükleyin, kurun, gidin.
Ve versiyonlanmış proje dosyaları sayesinde buna sahibiz.