Являются ли объявления репозитория Maven транзитивными?

#maven

#maven

Вопрос:

Предположим, у меня есть следующий проект, библиотека, которая объявляет какой-то сторонний репозиторий, который ему необходимо использовать для захвата артефакта.

 <project ...>
    <groupId>com.mygroup</groupId>
    <artifactId>library</artifactId>
    <version>1.0.0</version>

    <repositories>
        <repository>
            <id>some-id</id>
            <url>https://some.repo.com</url>
        </repository>
    </repositories>

    <dependencies>
        <dependency>
            <groupId>com.thirdparty</groupId>
            <artifactId>used-at-compile-time</artifactId> <!-- like Lombok, say -->
            <version>1.0.0</version>
            <scope>provided</scope> <!-- so, not transitive -->
        </dependency>
    </dependencies>
</project>
  

Тогда у меня есть совершенно отдельный проект, который зависит от этой библиотеки

 <project ...>
    <groupId>com.mygroup</groupId>
    <artifactId>some-app</artifactId>
    <version>2.0.0</version>

    <dependencies>
        <dependency>
            <groupId>com.mygroup</groupId>
            <artifactId>library</artifactId>
            <version>1.0.0</version>
        </dependency>
    </dependencies>
</project>
  

Пытается ли Maven включить определение репозитория во все зависимые проекты? some-app Когда-нибудь попытается получить доступ https://some.repo.com ?

У меня всегда было впечатление, что этого не произошло, но я начал видеть сбои сборки, которые ограничивают это убеждение.

Поначалу это может показаться удобным, если так оно и работает, но что, если репозиторий был внутренним и не был общедоступен через Интернет? Проект, который объявил его, может использовать его для некоторых зависимостей во время компиляции, как в моем примере выше. Если бы это репозиторий был затянут, зависимый проект мог бы попытаться получить доступ к репозиторию, который он не может получить для некоторых других зависимостей, отличных от Maven Central.

Итак, я вижу веские причины для любого поведения, но, насколько я вижу, в документации для репозиториев так или иначе не говорится о том, что происходит, как и в ссылке на POM.

Комментарии:

1. Я также подозреваю , что эти репозитории читаются. Это одна из причин, по которой я использую <mirrorOf>*</mirrorOf> конфигурацию в своем settings.xml . Кроме того, Artifactory имеет стандартную конфигурацию для исключения определений репозитория из POM, что также указывает на то, что они не игнорируются.

2. @JFabianMeier Ваш комментарий вдохновил меня на проверку плагина flatten , который TL; DR удаляет посторонние детали. По умолчанию он говорит, что не удаляет их (хотя вы можете настроить его для этого), что, опять же, подтверждает тот факт, что они транзитивны. Было бы неплохо, если бы был источник, в котором это явно указано.

3. @JFabianMeier верно, хотя это также может указывать на их исключение из родительских pom или, например, из импортированных pom. Те, которые будут более непосредственно «включены» в сам ссылающийся проект. Хотя я не могу это доказать, мне было бы довольно странно, если бы maven автоматически начал использовать репозитории, определенные в pom простой зависимости, особенно зависимости, которая даже не упакована с возможностью развертывания. Тем не менее … это чертовски хороший вопрос.

4. Вероятно, вопрос к мистеру Марбезу или мистеру Шолте.

5. Я согласен… Я взял на себя смелость отправить электронное письмо mr. Подробнее об этом. Удача благоволит смелым.

Ответ №1:

Репозитории учитывают контекст в контексте своего pom. Зависимости от com.mygroup:library могут использовать репозитории central и some-id . С другой стороны, зависимости от com.mygroup:some-app будут использовать только central . При запуске Maven из командной строки вы увидите репозитории, из которых он попытается загрузить артефакты (в случае сбоя первого, он перейдет к следующему).

При публикации в Central существует несколько требований. Однако, основываясь на последнем абзаце, репозитории не запрещены, вам рекомендуется не использовать их.

Возможно, вы не захотите читать эту классическую статью: Почему размещение репозиториев в ваших POMS — плохая идея

Комментарии:

1. Кстати, я случайно посмотрел ваше выступление с прошлогоднего Devoxx ранее сегодня (после того, как @Gimby прокомментировал, что отправил вам электронное письмо), и это было превосходно!

2. Спасибо вам за просмотр. Что касается документов, это может быть задокументировано в одной из книг Maven. Он довольно продвинутый и не рекомендуется использовать.

3. Нет проблем. Несмотря на все свои недостатки, StackOverflow имеет большое присутствие в Google, поэтому, надеюсь, этого вопроса будет достаточно, чтобы удовлетворить всех, кто заинтересован. Я думаю, вы можете судить по количеству просмотров, которые он в конечном итоге получает, стоит ли давать дополнительные объяснения в документах или нет.