2016-11-15 6 views
0

Это обычный вариант использования нескольких автономных проектов, которые связаны друг с другом. Например, некоторые общие библиотеки утилит. С Maven вы можете просто установить измененную зависимость локально, чтобы она использовалась при создании зависимого проекта. Я всегда считал эту функциональность само собой разумеющимся (IDE также поддерживают это).Maven как местный репозиторий с Gradle

Но с Gradle я не нашел ничего подобного. Я не хочу, чтобы локальная установка Maven (в чем смысл Gradle), чтобы иметь возможность устанавливать артефакты локально. Также я не хочу зависеть от CI, поскольку во время разработки программисты любят повторять до тех пор, пока они не будут довольны API. Было бы много бесполезных коммитов просто для компиляции и установки в наш Nexus.

Есть ли какая-либо передовая практика, как управлять местной разработкой или связанными с ней проектами, которые не имеют общего корня?

+0

Я считаю, что то, что вы считаете само собой разумеющимся, на самом деле является чем-то нарушающим то, что Maven нацелило на обеспечение: Воспроизводимой сборки. Во всяком случае, эквивалент Gradle локального репо Maven в некоторых расширениях - это кеш под '.gradle' в вашем местном доме. –

+0

Я понимаю вашу точку зрения, но поскольку местная разработка требует использования CI для итеративной работы, это будет кошмар производительности и репозитория. Насколько я понимаю, кеш Gradle не является решением. Он предназначен только для кеша, и в него не должны быть установлены артефакты. –

+0

Я не понимаю вашу точку. Во всяком случае, почему бы просто не добавить репозиторий, который является локальным каталогом в вашей конфигурации gradle? или просто добавьте 'mavenLocal()' в качестве одного из ваших репозиториев. –

ответ

0

Во-первых, вы можете опубликовать/эталонные банки в mavenLocal() без Maven установлен (это просто каталог, который Gradle умеет читать/писать)

Во-вторых, Gradle создаст PublishToMavenLocal задачу для каждого MavenPublication в вашей постройте, чтобы вы могли использовать их для установки банок в %USER_HOME%/.m2

И В-третьих ... забудьте о моих первых и вторых точках. Если вы не хотите использовать mavenLocal(), вы можете использовать новую функцию composite build, добавленную в Gradle 3.1. По-моему, эта функция намного лучше, чем mavenLocal, поскольку баны с моментальным снимком никогда не будут удалены удаленно после истечения срока действия, и вместо этого локальные источники всегда будут использоваться. Это несколько раз сбивало меня с maven, где устаревали локально установленные фреймы-копии.

+0

Я прочитал на форуме Gradle, что разрешение mavenLocal() реализовано задачей Ant, в которой логика для поиска репозитория жестко запрограммирована и только способ изменить ее местоположение используя .m2/settings.xml. В любом случае я согласен с тем, что составные сборки выглядят как лучший вариант. –

Смежные вопросы