Gradle: сделать стороннюю банку доступной для локального хранилища gradle

В настоящее время я тестирую Gradle как альтернативу Maven. В моих проектах есть некоторые сторонние банки, которые недоступны в каких-либо (Maven) репозиториях. Моя проблема теперь, как я могу управлять им, чтобы установить эти банки в мой локальный репозиторий .gradle. (Если возможно, я не хочу использовать локальный репозиторий Maven, потому что Gradle должен работать независимо.) На данный момент я получаю много исключений из-за недостающих банок. В Maven это довольно просто, выполнив команду установки. Однако мой поиск в Google для чего-то похожего на команду установки Maven не увенчался успехом. У кого-нибудь есть идея?

ОТВЕТЫ

Ответ 1

вы можете включить зависимости JAR в файловой системе как:

dependencies {
    runtime files('libs/a.jar', 'libs/b.jar')
    runtime fileTree(dir: 'libs', include: '*.jar')
}

вы можете изменить время выполнения для compile/testCompile/etc..

Ответ 2

Более подробный ответ был дано в списке рассылки Адамом Мердоком по адресу http://gradle.1045684.n5.nabble.com/Gradle-Make-a-3rd-party-jar-available-to-local-gradle-repository-td1431953.html

По состоянию на апрель 2010 года не было простого способа добавить новый jarfile в ваш репозиторий ~/.gradle. В настоящее время выясняется, изменилось ли это.

По состоянию на октябрь 2014 года это все равно, потому что gradle выполняет контрольную сумму md5 вашего jarfile, вы не можете просто загрузить его и поместить в каталог под .gradle/caches и gradle не имеет, насколько я могу судить, задачи, которые позволяют взять локальный файл и вставить его в его кеш.

Ответ 3

Использованный вариант (1) из сообщения Адама Мердока (уже связанный выше: http://gradle.1045684.n5.nabble.com/Gradle-Make-a-3rd-party-jar-available-to-local-gradle-repository-td1431953.html) с gradle -1.3, и он работает просто приятно!

Вот его комментарий:

  • Скопируйте банки в локальный каталог и используйте репозиторий flatDir(), чтобы использовать их там. Например, вы можете скопировать их в $projectDir/lib и в вашем файле сборки:

репозитории {      flatDir (dirs: 'lib')}

Файлы в каталоге lib должны следовать схеме именования: name-version-classifier.extension, где версия и классификатор необязательный. Так, например, вы можете назвать их groovy -1.7.0.jar или даже groovy.jar

Затем вы просто объявляете зависимости как обычно:

зависимости {     compile 'groovy: groovy: 1.7.0'}

Здесь немного больше одного репозитория flatDir(): http://gradle.org/0.9-preview-1/docs/userguide/dependency_management.html#sec:flat_dir_resolver

  1. Аналогично вышеизложенному, но с использованием распознавателя плюща вместо flatDir(). Это почти то же самое, что и выше, но позволяет есть много вариантов, поскольку имена и местоположения идут.

Есть некоторые детали: http://gradle.org/0.9-preview-1/docs/userguide/dependency_management.html#sub:more_about_ivy_resolvers

  1. Не заморачивайся с объявлением зависимостей. Просто скопируйте банки в локальный каталог и добавьте зависимость файла. Например, если банки находятся в $projectDir/lib:

зависимости {      compile fileTree ('lib')//включает в себя все файлы под "lib" в пути к компиляции class

Подробнее: http://gradle.org/0.9-preview-1/docs/userguide/dependency_management.html#N12EAD

  1. Используйте maven install для установки зависимостей в вашем локальном кэше maven и используйте кеш maven как репозиторий:

репозитории {      mavenRepo (urls: new File (System.properties ['user.home'], '.m2/repository'). toURI(). toURL())}

Ответ 4

Возможно, мне не хватает чего-то из моего чтения вашего вопроса, если ваш репозиторий gradle имеет тип flatDir, вы должны иметь возможность копировать файлы там в форме myjar-1.0.jar и разрешать их как myjar версии 1.0.

Не знаете, почему необходимо, чтобы gradle запускал maven для доступа к локальному репозиторию maven. Вы можете просто определить maven-репозитории, и он должен разрешать зависимости. Вы можете использовать gradle upload для подталкивания локальных или удаленных репозиториев maven, если вам нужно. В этом случае он выполнит maven.

Ответ 5

Короче: развертывание в диспетчере хранилищ. Он может локально, в локальной сети.

Совсем другой способ мышления об этом типе проблемы, особенно если это происходит часто, заключается в использовании диспетчера репозитория. Есть некоторые отличные варианты с открытым исходным кодом, такие как Artifactory, Nexus или Archiva.

Предположим, что у вас есть файл jar из некоторого сомнительного происхождения, который должен быть включен в вашу сборку, пока у вас не будет возможности реорганизовать его. Менеджер хранилища позволит вам загрузить файл в ваш собственный репозиторий, так как для этого примера dubious-origin-UNKNOWN.jar

Тогда ваш build.gradle будет выглядеть примерно так:

repositories {
    mavenRepo urls: "http://your.own.repository/url";
}

dependencies {
    compile "dubious:origin:UNKNOWN";
}

Есть много других преимуществ для использования менеджера хранилища, такого как кеширование удаленных артефактов, удаление артефактов из scm, промежуточных выпусков, более подробные разрешения пользователя и т.д.

В нижней части вы добавляете сервер, который несет некоторые служебные накладные расходы, чтобы ваши сборки работали.

Я полагаю, зависит от размера вашего проекта.

Ответ 6

Я думаю, что что-то вроде этого должно работать:

dependencies {
  files('yourfile.jar')
}

Он работает для вас?