2011-05-16 114 views
0

我有一個多項目設置(ProjectB - > ProjectA),我使用flatDir在每個項目中指定一個lib目錄。我的gradle配置在構建期間沒有使用正確的類路徑

項目A:

repositories { 
    flatDir name: 'localRepository', dirs: 'lib' 
} 

dependencies { 
    compile group: 'com.google.guava', name: 'guava', version: 'r08' 
    compile group: 'com.miglayout', name: 'miglayout', version: '3.7.4' 
    testCompile group: 'junit', name: 'junit', version: '4.+' 
    testCompile group: 'org.easymock', name: 'easymock', version: '2.5.2' 
} 

項目B:

repositories { 
    flatDir name: 'localRepository', dirs: 'lib' 
} 

dependencies { 
    compile group: 'yan', name: 'yan', version: '5.0.2' 
    runtime group: 'yan', name: 'jfunutil', version: '5.0.2' 
    compile project(':ProjectA') 
    testCompile group: 'junit', name: 'junit', version: '4.+' 
    testCompile group: 'org.easymock', name: 'easymock', version: '2.5.2' 

}

當我使用gradle dependencies爲項目B,將產生正確的依存列表,示出傳遞依賴從項目A(例如,包括番石榴-R08)。但是,如果爲gradle build,則用於javac的實際類路徑只包含ProjectB的直接依賴項以及構建ProjectA生成的jar。

另一個煩惱是它似乎爲testCompile,我不得不重新聲明依賴項目B的junit,否則gradle dependencies將不會成功。

任何指針非常讚賞 - 我是新來的Gradle。

回答

1

關於你的項目結構...

這似乎是一個更好的主意,有,而不必爲每個項目一個lib文件夾。

你的目錄結構是這樣的:

project/settings.gradle 
project/ProjectA/lib 
project/ProjectA/src 
project/ProjectB/lib 
project/ProjectB/src 

你爲什麼要爲每個子項目一個lib文件夾中有什麼特別的原因嗎?這似乎是一個更好的主意:

project/settings.gradle 
project/lib 
project/ProjectA/src 
project/ProjectB/src 

可以創建項目(項目/的build.gradle)的根目錄中的build.gradle包含以下內容:

subprojects{ 
    apply plugin: 'java' 
    repositories { 
     flatDir name: 'localRepository', dirs: "$rootProject.projectDir/lib" 
    } 
} 

這種方式可以把你所有的依賴關係放到project/lib中。

關於你的測試depencendies ...

您也可以將您的testCompile依賴這個根的build.gradle文件。它變爲:

subprojects{ 
    apply plugin: 'java' 
    repositories { 
     flatDir name: 'localRepository', dirs: "$rootProject.projectDir/lib" 
    } 
    dependencies{ 
     testCompile group: 'junit', name: 'junit', version: '4.+' 
     testCompile group: 'org.easymock', name: 'easymock', version: '2.5.2' 
    } 
} 

這樣你就不必指定每個子項目的的build.gradle文件testCompile依賴。

然而,當我搖籃建立,用於爲javac 實際classpath中只 包括 項目B的直接依賴,並通過 建設項目A產生的罐子。

爲了編譯ProjectB,你只需要ProjectA。只有ProjectA是你的編譯依賴; ProjectA編譯依賴項成爲ProjectB的傳遞依賴項。

+0

感謝您的建議,但也許我簡化了太多的東西。這個想法是ProjectA是一個通用庫。它包含我的常用工具等,並且我有3個其他項目(應用程序)依賴於ProjectA。項目A應完全獨立於其他項目,另外項目(項目B,C,D)彼此獨立。這就是爲什麼我不那麼熱衷於全球網絡概念以及分層次的項目結構。 (儘管我並未完全否認這一點 - 所以非常感謝你的努力!) – zorgbargle 2011-05-17 18:22:33

0

我同意上一個答案。多次嘗試後,我們有相同的結構

> shared 
- build.gradle 
- gradle.properties 
- settings.gradle 
> project-a 
- gradle.properties 
- settings.gradle 
> project-b 
- gradle.properties 
- settings.gradle 

共享具有所有共同的代碼,在我們的情況下,它處理簽到,模塊部署,代碼質量(的Cobertura),編譯等 共享還定義了類路徑,其是由子項目繼承,然後可以添加其他依賴項。

對於您的問題:

你有沒有定義在項目中的以下?

settings.gradle includeFlat( '項目B')

你有沒有定義在項目B以下?

settings.gradle includeFlat( 'A計劃')

+0

這看起來與以前的答案略有不同:在上一個答案中,似乎共享lib文件夾是在根項目中定義的,而ProjectA和ProjectB是根的子項目。在你的情況下,它看起來像共享是項目a和項目b的兄弟姐妹。我的偏好是這樣一個扁平的層次結構。考慮我是否共享a和共享b(兩個獨立的核心項目可供應用級項目使用,請問您的解決方案是否支持這種結構?謝謝! – zorgbargle 2011-05-23 20:45:58

+0

是的,這就是我們如何使用它,如果你願意,我會發布更多的細節,但我想你現在可能已經弄清楚了,我只是做了一個非常簡單的項目,並得到了結構的工作,然後我添加了所有真正的代碼。我發現與Gradle的問題是文檔不是足夠成熟,你永遠不知道哪個是最好的辦法。我希望這不是一個由於學習資源不足而消失的項目。 – 2011-05-25 09:48:49

+0

謝謝,仍然卡住了:我嘗試過項目B:includeFlat('Project A')。因爲B依賴於A,所以我不希望爲A使用includeFlat('B項')(A不應該知道B的任何內容)。我的構建現在在執行Gradle構建時失敗了 - Gradle確定它必須先構建A(是),但隨後嘗試解決A對B的lib文件夾的jar依賴關係(不!),因此它找不到任何Jar和項目A獲勝不會編譯。這很令人沮喪,因爲它看起來像你的結構正是我所追求的 - 謝謝! – zorgbargle 2011-05-30 21:05:23

0

在原崗位的構建腳本都很好。傳遞性依賴解析不起作用的原因是項目只會使用自己的存儲庫來解析其配置。因此,解決您的問題的一種方法是隻有一個lib目錄。另一個解決方案是爲B聲明第二個存儲庫,指向A的lib目錄。

另一個煩惱是它似乎爲testCompile,我不得不重新聲明依賴於ProjectB的junit,否則gradle依賴將不會成功。

不知道你在這裏說什麼,但它可能是我上面解釋的結果。也許下面的信息也有幫助:根據項目不會拉動它的testCompile/testRuntime依賴關係。預計您必須爲每個需要它的項目聲明JUnit。爲了避免重複,您可以使用configuration injection來聲明項目之間的共同點。以前的答案已經給出了具體的例子(例如subprojects { ... })。