Çok Sayfalı Çok Katlı Proje Kurulumu Kurulumu

Kısa süre önce Gradle'ı kullanmaya ve mevcut Maven tabanlı projelerimi değiştirmeye başladım. Geçmişte Maven ile çok modüllü yapıların işlenmesiyle ilgili birçok sorun yaşadım. Çok modüllü builleri ele alırken Gradle, temiz hava soludu, ama henüz mükemmel değil.Çok Sayfalı Çok Katlı Proje Kurulumu Kurulumu

benim projeler için aşağıdaki klasör düzeni:

-- Projects 
---- EnterpriseApp1 
------ EarProject 
-------- build.gradle 
------ EjbProject 
-------- build.gradle 
------ WarProject 
-------- build.gradle 
------ properties.gradle 
------ build.gradle 
---- CommonLib 
------ build.gradle 
---- ClientApplication 
------ build.gradle

ben yaşıyorum sorun "EnterpriseApp1" ve "clientapplication" hem CommonLib projede bağımlı olmasıdır. "EjbProject" için CommonLib projesini bağımlı olarak kullanmak için "EnterpriseApp1" yapı dosyasını nasıl yapılandıracağımı bilmiyorum. Bunu işe almak için çok yaklaştım ama henüz tam çalışmıyor. "EnterpriseApp1" içindeki CommonLib klasörünü kopyalayarak başarılı oldum, ancak bu uzun vadeli bir çözüm değil. "Settings.gradle" dosyasında "includeFlat" komutu ile aynı kolu projeler yer alacak Gradle belgelerine göre

include "EarProject", "EjbProject", "WarProject" 
includeFlat "CommonLib"

İşte benim şimdiki properties.gradle "EnterpriseApp1" dosya var "settings.gradle" dosyasının bulunduğu klasör (istenen davranış).

EnterpriseApp1/build.gradle dosyası:

subprojects { 
    apply plugin: 'java' 

    sourceCompatibility = 1.6 
    group = 'org.example' 
    version = '1.0-SNAPSHOT' 

    repositories { 
     mavenCentral() 
     ... 
    } 

    dependencies { 

    }  
}

EnterpriseApp1/EjbProject/build.gradle: Ben EnterpriseApp1 klasöründen "gradle temiz bir yapı" yürütme zaman

apply plugin: 'java' 

sourceCompatibility = 1.6 

repositories { 
    mavenCentral() 
    ... 
} 

dependencies { 
    compile project(':CommonLib') 

    compile group: 'org.restlet.jee', name: 'org.restlet', version: '2.0.11' 
    compile group: 'ma.glasnost.orika', name: 'orika-core', version: '1.0' 
    ... 
    compile group: 'javax.jmdns', name: 'jmdns', version: '3.4.1' 
}

tüm bağımlılıkları indirilir beklendiği gibi ve projeler derlenmeye başlar (CommonLib projesi dahil), ancak EjbProject projesi, CommonLib jar başvurusu eksik olduğundan, yapı sırasında başarısız olur. EjbProject'imi CommonLib proje oluşturma aşamasından oluşturulan Jar'i kullanacak şekilde yapılandırmak için yeterince akıllı değil (veya tamamen clueless;)).

Uzun ve karmaşık kurulum için özür dilerim. Bunu bir süredir çözmeye çalışmak için çalışıyorum, ama neredeyse fikir tükendi. Topluluk için herhangi bir yardımı gerçekten takdir ediyorum.

Teşekkürler!

kaynak

2012-01-26 juan.villa

Gösterilen dizin düzeninin girintisiyle ilgili bir sorun var. Bu, CommonLib ve ClientApplication EnterpriseApp1 ile aynı dizin düzeyinde bulunan bir yapı oluşturuyor mu ve diğer projeler bir seviye aşağı mı? (Bu çok nadir bir düzen olurdu. Genellikle ya bu ya da.) –

Ayrıca, Gradle, EjbProject/build.gradle'da böyle bir bağımlılık belirtmediğiniz sürece, CommonLib'in EjbProject'in bağımlılığı olduğunu bilmelidir? –

Söylemek istediniz mi: Burada "EnterpriseApp1" içinde şu anki _settings.gradle_ dosyası var –

Seçtiğiniz dizin düzeni zaten iyi bir çözümde ipucu veriyor. Üç ayrı yapıya sahip olmanızı öneririm: EnterpriseApp1, CommonLib ve ClientApplication. Bir Maven veya Ivy deposuna CommonLib yayınlayacağım, böylece diğer iki yapı onu buradan tüketebilir. Yerel gelişim için yerel Maven repo'ya (en kolay) veya dosya tabanlı Ivy repo'ya CommonLib yayınlayabilirsiniz.

kaynak

2012-01-27 04:36:42

Teşekkür ederim Peter! Son çare olarak yapabileceğimi düşünüyordum ama yerel/uzak bir repo kullanmak zorunda kalmak istemedim. Gradle ile bunun mümkün olup olmadığını biliyor musunuz? ya da bunun ilk etapta iyi bir uygulama olmadığını mı düşünüyorsunuz? –

“EnterpriseApp1” ve “ClientApplication” farklı bir geliştirme ve sürüm döngüsü olan farklı uygulamalar ise, yapı bunu yansıtmalıdır. 'CommonLib'ı' EnterpriseApp1' adlı yapının bir parçası olarak yayınlayabilirsiniz, ancak bu yine de bir depo gerektirecektir ve ClientApplication'ın 'CommonLib'de bir değişiklik yapması gerektiğinde sorunları karmaşıklaştıracaktır. Alternatif olarak, tüm kod aynı kaynak deposundaysa, her ikisi de 'CommonLib' içeren iki yapıya sahip olabilirsiniz. Ya da geliştirme/sürüm döngüleri aynıysa, büyük bir yapıya sahip olabilirsiniz, bu durumda bir repoya ihtiyacınız olmaz. –

Anlam veriyor. Teşekkürler Peter! –

Çok Sayfalı Çok Katlı Proje Kurulumu Kurulumu

cevap

İlgili konular