Моя конфигурация gradle не использует правильный путь к классу во время сборки - PullRequest
Новая
       19

Моя конфигурация gradle не использует правильный путь к классу во время сборки

0 голосов
/ 17 мая 2011

У меня есть настройка нескольких проектов (ProjectB -> ProjectA), и я использую flatDir для указания одного каталога lib в каждом проекте.

ProjectA: 

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

ProjectB: 

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 для ProjectB, генерируется правильный список зависимостей, показывающий транзитивные зависимости от ProjectA (например, включая guava-r08). Однако, когда я gradle build, фактический путь к классу, используемый для javac, включает только прямые зависимости ProjectB и jar-файл, созданный при построении ProjectA.

Еще одна неприятность заключается в том, что для testCompile кажется, что я должен повторно объявить зависимость от junit для ProjectB, иначе gradle dependencies не будет успешным.

Любые указатели очень ценятся - я новичок в Gradle.

Ответы [ 3 ]

1 голос
/ 17 мая 2011

О структуре вашего проекта ...

Лучше всего иметь одну папку 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 в корневом каталоге проекта (project / build.gradle), который содержит следующее: 

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

Таким образом, вы можете сбросить все ваши зависимости в проект / lib.

О ваших тестовых зависимостях ...

Вы также можете поместить свои зависимости 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'
   }
}

Таким образом, вам не нужно указывать зависимость testCompile в файле build.gradle каждого подпроекта.

Однако, когда я собираюсь строить, фактический путь к классу используется только для javac включает в себя прямые зависимости ProjectB, и банка, сгенерированная Здание Проекта.

Чтобы скомпилировать ProjectB, вам нужен только ProjectA. Только ProjectA - ваша зависимость от компиляции; Компиляционные зависимости ProjectA становятся переходными зависимостями ProjectB.

0 голосов
/ 17 мая 2012

Сценарии сборки в вашем исходном посте в порядке. Причина, по которой транзитивное разрешение зависимостей не работает, заключается в том, что проект будет использовать свои собственные репозитории только для разрешения своих конфигураций. Следовательно, один из способов решить вашу проблему - это иметь только один каталог lib. Другое решение состоит в том, чтобы объявить второй репозиторий для B, который указывает на каталог lib A.

Еще одна неприятность, похоже, для testCompile, я должен повторно объявить зависимость от junit для ProjectB, иначе зависимости gradle не будут успешными.

Не уверен, что вы говорите здесь, но это может быть следствием того, что я объяснил выше. Может быть, также поможет следующая информация: В зависимости от проекта не учитываются зависимости testCompile / testRuntime. Ожидается, что вы должны объявить JUnit для каждого проекта, который в этом нуждается. Чтобы избежать повторения, вы можете использовать внедрение конфигурации , чтобы объявить сходство между вашими проектами. Предыдущие ответы уже давали конкретные примеры для этого (например, subprojects { ... }).

0 голосов
/ 19 мая 2011

Я согласен с предыдущим ответом. После нескольких попыток мы имеем ту же структуру 

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

Shared имеет весь общий код, в нашем случае он обрабатывает проверки, развертывание модулей, качество кода (cobertura), компиляцию и т. Д. Shared также определяет путь к классам, который наследуется подпроектами, которые затем могут добавлять дополнительные зависимости.

Для вашей проблемы:

Вы определили следующее в своем проекте A?

settings.gradle includeFlat ('Проект B')

Вы определили следующее в проекте B?

settings.gradle includeFlat ('Project A')

...