Comments 13
Хотя я и сомневаюсь что стоит дублировать абсолютно все пакеты (это встречается в экосистеме Maven для Java)maven приносит только одну версию каждой зависимости. Базовое описание: maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html.
Я думаю, вы правы. Отправил автору оригинальной статьи email, попросил уточнить что конкретно он имел ввиду.
Ответ автора оригинальной статьи:
The comment was based on the existence of this Maven rule:
maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html
which seems to imply that A and B can depend on different versions of C.
I could certainly believe that by default Maven makes everything
default, I haven't used it for any big projects.
Edward
По умолчанию, maven будет пытаться определить наиболее подходящую версию библиотеки, от которой транзитивно зависит проект. Процитирую кусочек из описания, ссылку на который я дал:
Сделано это потому, что иначе жить невозможно не раздувая зависимости. Например, используете вы две библиотеки, которые указали зависимостями разную минорную версию какого-нибудь slf4j-api (библиотека для логгирования). Интерфейсы одни и те же, но проект перестал собираться, если не выбрать одну версию. И переубедить разработчика библиотек A, B и C, что они должны использовать одну версию D почти невозможно.
Поэтому всегда есть возможность указать явно, какую версию использовать. В случае, когда совсем приспичит (если в проекте необходимо иметь две несовместимые версии библиотеки), можно использовать shade plugin, который позволяет переименовать их и поправить зависимости.
Если нужно, чтобы при расхождении версий зависимостей нельзя было собрать проект, то есть enforcer plugin. Это не значит, что необходимо навязывать такое поведение. Это следует, как минимум, из того, что в рантайме может оказаться другая версия зависимости, что является вполне нормальным.
Другое дело, что это требует большей дисциплины от разработчиков библиотек. Но, в этом случае, оно и нормально.
Ситуация принципиально не отличается от динамических библиотек, линкуемых через ld.so (в linux, например), когда в системе может оказаться иная версия, нежели та, против которой линковалась программа.
Dependency mediation — this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the «nearest definition» which means that it will use the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, until Maven 2.0.8 it was not defined which one would win, but since Maven 2.0.9 it's the order in the declaration that counts: the first declaration wins.
- «nearest definition» means that the version used will be the closest one to your project in the tree of dependencies, eg. if dependencies for A, B, and C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0
Сделано это потому, что иначе жить невозможно не раздувая зависимости. Например, используете вы две библиотеки, которые указали зависимостями разную минорную версию какого-нибудь slf4j-api (библиотека для логгирования). Интерфейсы одни и те же, но проект перестал собираться, если не выбрать одну версию. И переубедить разработчика библиотек A, B и C, что они должны использовать одну версию D почти невозможно.
Поэтому всегда есть возможность указать явно, какую версию использовать. В случае, когда совсем приспичит (если в проекте необходимо иметь две несовместимые версии библиотеки), можно использовать shade plugin, который позволяет переименовать их и поправить зависимости.
Если нужно, чтобы при расхождении версий зависимостей нельзя было собрать проект, то есть enforcer plugin. Это не значит, что необходимо навязывать такое поведение. Это следует, как минимум, из того, что в рантайме может оказаться другая версия зависимости, что является вполне нормальным.
Другое дело, что это требует большей дисциплины от разработчиков библиотек. Но, в этом случае, оно и нормально.
Ситуация принципиально не отличается от динамических библиотек, линкуемых через ld.so (в linux, например), когда в системе может оказаться иная версия, нежели та, против которой линковалась программа.
UFO just landed and posted this here
UFO just landed and posted this here
Со временем они все же могут интегрироваться, использоваться вместе, становиться более логичными и удобными. Пакетные менеджеры — подход, что пока развивается и потому логично что на данный момент они просто плодятся и только начинают идти к каким-то стандартам, удобным подходам.
Например — в новой версии Visual Studio (2015) можно из коробки использовать NPM и Bower, кроме пакетного менеджера от Майкрософт (nuget).
Например — в новой версии Visual Studio (2015) можно из коробки использовать NPM и Bower, кроме пакетного менеджера от Майкрософт (nuget).
Давайте я вам ещё более страшную историю расскажу. Это когда исходный текст зависит от библиотек без версий. При этом на билд-серверах разработчика версии пришпилены, а у всех остальных — head, какой придётся. И этот head сам с собой, а так же с несколькими явно указанными версиями конфликтует. До кучи добавим ещё зависимость от новой версии пакетного менеджера, который зависит от новой версии компилятора, причём компилятор должен ставиться новой версией пакетного менеджера, а менеджер — компилироваться новым компилятором. И со старыми оно работает с глюками или не работает вовсе.
И это не какая-то непонятная ерунда, это центральная часть xenserver — xapi: github.com/xapi-project/xen-api. С годами у них стало легче, но не сильно. Я до сих вздрагиваю, когда вспоминаю.
И это не какая-то непонятная ерунда, это центральная часть xenserver — xapi: github.com/xapi-project/xen-api. С годами у них стало легче, но не сильно. Я до сих вздрагиваю, когда вспоминаю.
А ведь в ситуации свой пакетный менеджер для каждого языка есть и плюсы. Менеджер может анализировать интерфейсы библиотек и прогонозировать совместимость версий на уровне «скомпилится». Согласен, не много, но тоже не плохо.
Sign up to leave a comment.
Фундаментальная проблема пакетных менеджеров для языков программирования