2012-01-26 6 views
19

Niedawno zacząłem używać Gradle i zastępować moje istniejące projekty oparte na Maven. W przeszłości miałem wiele problemów z obsługą wielomodułowych buildów z Maven. Gradle był powiewem świeżego powietrza podczas obsługi wielomodułowych modułów, ale nie jest jeszcze doskonały.Wieloklatkowa konfiguracja projektu Gradle

Mam następujący układ folderów dla moich projektów:

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

Problem mam jest to, że „EnterpriseApp1” i „ClientApplication” zarówno zależą od projektu CommonLib. Nie wiem, jak skonfigurować plik kompilacji "EnterpriseApp1", aby wykorzystać projekt CommonLib jako zależność dla "EjbProject". Bardzo się do tego zbliżyłem, ale jeszcze nie do końca. Odniosłem sukces, kopiując folder CommonLib wewnątrz "EnterpriseApp1", ale to nie jest rozwiązanie długoterminowe.

Oto mój obecny plik properties.gradle w „EnterpriseApp1”:

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

Według dokumentacji Gradle komenda „includeFlat” w „settings.gradle” plik będzie obejmować projekty w tej samej dźwigni jako folder, w którym znajduje się plik "settings.gradle" (pożądane zachowanie).

EnterpriseApp1 plik/build.gradle:

subprojects { 
    apply plugin: 'java' 

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

    repositories { 
     mavenCentral() 
     ... 
    } 

    dependencies { 

    }  
} 

EnterpriseApp1/EjbProject/build.gradle:

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' 
} 

Kiedy wykonać "Gradle czystą kompilację" z folderu EnterpriseApp1 wszystkie zależności są pobierane zgodnie z oczekiwaniami, a projekty zaczynają się kompilować (w tym projekt CommonLib), ale projekt EjbProject kończy się niepowodzeniem podczas kompilacji, ponieważ brakuje w nim odwołania do jarów CommonLib. Gradle nie jest wystarczająco inteligentny (lub jestem całkowicie nieświadomy;)), aby skonfigurować mój EjbProject do korzystania z Jar wygenerowany z etapu budowy projektu CommonLib.

Przepraszam za długą i skomplikowaną konfigurację. Od pewnego czasu próbuję to rozgryźć, ale prawie zabrakło pomysłów. Naprawdę doceniam każdą pomoc dla społeczności.

Dzięki!

+0

Coś jest nie tak z pokazanym wcięciem wyświetlanego katalogu. Czy to jedna z wersji, w której CommonLib i ClientApplication znajdują się na tym samym poziomie katalogów co EnterpriseApp1, a pozostałe projekty są o jeden poziom niżej? (To byłby bardzo nietypowy układ, zwykle jest to albo.) –

+0

Również, w jaki sposób Gradle powinien wiedzieć, że CommonLib jest zależnością EjbProject, biorąc pod uwagę, że nie określa się takiej zależności w 'EjbProject/build.gradle'? –

+0

Czy masz zamiar powiedzieć: Oto mój aktualny plik _settings.gradle_ w "EnterpriseApp1" –

Odpowiedz

7

Układ folderów, który już wybrałeś, wskazuje na dobre rozwiązanie. Proponuję trzy osobne kompilacje: EnterpriseApp1, CommonLib i ClientApplication. Opublikuję CommonLib do repozytorium Maven lub Ivy, aby pozostałe dwie wersje mogły go pobrać. W celu rozwoju lokalnego możesz opublikować numer CommonLib w lokalnym repozytorium Maven (najłatwiej) lub repozytorium Ivy opartym na plikach.

+0

Dziękuję Peter! Myślałem, że mogę to zrobić w ostateczności, ale nie chciałem korzystać z repozytorium lokalnego/zdalnego. Czy wiesz, czy jest to możliwe do osiągnięcia przez Gradle? Czy uważasz, że to nie jest dobra praktyka? –

+2

Jeśli "EnterpriseApp1" i "ClientApplication" to różne aplikacje z innym cyklem rozwoju i wydania, kompilacja powinna to odzwierciedlać. Możesz opublikować 'CommonLib' jako część' EnterpriseApp1' build, ale to nadal będzie wymagało repozytorium i skomplikuje sprawy, gdy 'ClientApplication' potrzebuje zmiany w' CommonLib'. Alternatywnie, jeśli cały kod znajduje się w tym samym źródłowym repozytorium, możesz mieć dwie kompilacje, z których obie zawierają "CommonLib". Lub, jeśli cykle rozwoju/wydania są takie same, możesz mieć jedną dużą kompilację, w takim przypadku nie będziesz potrzebował repozytorium. –

+0

Ma sens. Dzięki Peter! –