управление зависимостью со знатоком

Вы также можете исключить некоторые транзитивные зависимости, такие как следующий пример:

<dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>1.2.15</version>
        <exclusions>
            <exclusion>
                <groupId>javax.mail</groupId>
                <artifactId>mail</artifactId>
            </exclusion>
            <exclusion>
                <groupId>javax.jms</groupId>
                <artifactId>jms</artifactId>
            </exclusion>
            <exclusion>
                <groupId>com.sun.jdmk</groupId>
                <artifactId>jmxtools</artifactId>
            </exclusion>
            <exclusion>
                <groupId>com.sun.jmx</groupId>
                <artifactId>jmxri</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

Я не помню детали, но, по-видимому, некоторые другие зависимости были обнаружены, когда мы хотели использовать Log4J, и у нас не было интереса (или не нужно В них в нашем случае, поэтому моя корона Оркер только что сказала «Нет, благодаря этим», и это работает.

Во-первых, вопрос транзитивных зависимостей. Насколько я понимаю, если вы предоставляете зависимость, Maven в свою очередь найдет какие-либо зависимости этой зависимости. Это здорово, но для многих моих зависимостей это не сработало. (...)

Как уже указывалось, некоторые зависимости могут быть отмечены как необязательно (и не тянутся транзитивно). Идея состоит в том, что некоторые зависимости используются только для определенных функций и не будут необходимы, если эта функция не используется. Если пользователь хочет использовать функциональные возможности, связанные с дополнительной зависимостью, им придется Redeclare, что необязательная зависимость в собственном проекте. Так что это просто работает как разработано :)

Вторым - управление репозиториями. Maven поставляется с основным хранилищем по умолчанию, но я обнаружил, что во многих случаях этот репозиторий не в курсе. (...)

Даже если идея концепции Central Refo благородна, вы не можете объективно ожидать, что он содержит все банки в мире. Одной из наиболее очевидных причин является то, что загрузка артефактов в центральный репозиторий просто требует времени, а ресурсы не бесконечны. И поскольку компании, как Redhat Jboss или Springsource или Sun или даже мне нужна гибкость, реакционная способность (в одном слове, контроль), не удивительно, что они используют свой собственный репозиторий. И на самом деле, я довольно рад, что они подвергают их. Но действительно, проекты должны документировать, где найти свои артефакты, если они не доступны в центральном . На всякий случай, вы можете найти это Как найти зависимости на публичных репозиториях Maven? полезно. В корпоративной среде лучший способ справиться с этим, будет настроить централизованный (корпоративный) прокси-репозиторий. См. Эта страница для таких решений.

Тесно, связанные с номером 2, обеспечивающим правильную версию артефакта. (...)

Извините, но вам нужно немного знать, что вы делаете. Проект не может угадать для вас, какую версию JSTL вы собираетесь использовать. Затем, касающимся различных версий артефактов, Конвенция об именах, используемая проектами, не имеет ничего общего с Maven, это выбор проекта / поставщика (за исключением снимка, который обрабатывает мавена специально). FWIW, общие использованные схемы включают в себя: M1 = Milestone 1, RC1 = Commentiдент 1, GA = Общая доступность (окончательный выпуск), CR = выпуск клиента (часто выпуск исправления ошибок). Вы также можете увидеть альфа, бета. Это действительно зависит от жизненного цикла и конвенции проекта (здесь ничего не очень необычно).

Наконец, проблема типа зависимости. Я, наверное, просто не понимаю этого достаточно хорошо, но многие артефакты Reppo имеют тип «POM», а не «банку». (...)

Я думаю, что вы действительно не хватаете опыта. Кажется, вы боретесь с зависимостями, в то время как все просто проходят плавно для меня :) Может быть, используя поисковую систему .