2013-09-13 3 views
16

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

Например, у меня есть SomeProjectA, что зависит от SomeLibraryB. Мне нужен объем SomeLibraryB.

В настоящее время, чтобы скомпилировать все, что зависит от SomeProjectA, также необходимо установить SomeLibraryB. Я предпочел бы распространять эту область обзора, а затем иметь какой-либо проект, который зависит от моей сделки с иждивенцами моего проекта.

ответ

17

Я не думаю, что это возможно. Каждый проект должен самостоятельно объявлять предоставленные зависимости. Распространение этой области было бы неправильным, поскольку вы сделали бы предположение о развертывании, которое вы не можете сделать, поскольку не отвечаете за развертывание. Пользователь вашей библиотеки делает это.

+0

Спасибо за разъяснение. Вот что я подумал, просто хотел быть уверенным, что я не смутился. Проблема в том, что один из моих иждивенцев должен быть затенен, потому что платформа, которую я развертываю, предоставляет более старую версию. –

+0

Будьте осторожны при возвращении к более старым версиям. Там могут быть несовместимости .. –

-2

Как видно из Maven documentation, при условии, что область не влияет на компиляцию, но время исполнения. В общем случае вам нужно будет указать только предоставленную область в зависимостях для проекта упаковки, например проект типа war. По этой причине обычно не имеет большого значения, что она не является транзитивной.

Другими словами, если вы добавляете зависимость от проекта jar без явного указания его области видимости, эта зависимость будет доступна во время компиляции, а также зависимости зависимостей зависимостей. Если вы затем явно заявляете, что зависимость предоставила область, это не изменится.

+7

Извините, но это неправильно. Предоставленная область влияния влияет на компиляцию, но оставляет зависимости при упаковке проекта (например, на войне). На самом деле также имеет значение, что это не транзитивно, если бы оно было транзитивным, тогда все переходные зависимости были бы добавлены в путь компиляции class, и ваш модуль мог бы использовать все эти зависимости для компиляции. Это означало бы, что ваша зависимость имеет неявные компиляционные зависимости времени, которые являются _bad thing_. –

+2

Прошу прощения, но то, что я написал, является правильным. Установка зависимости к * при условии * не отличается от значения по умолчанию, которое является * компиляцией *, где компиляция. Неявные зависимости * * добавляются в путь к компиляции, независимо от того, определены ли они как * компиляция * или как * разделены *. При условии, что зависимости не добавляются к пути выполнения, но этот эффект не является рекурсивным. См. Http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html –

+1

Решение нашей разногласия находится на этой странице: «Эта область доступна только в пути к компиляции и тестированию, и не транзитивным ". Тот факт, что он не является транзитивным, означает, что переходные зависимости не приводятся во время компиляции. Поскольку зависимости исключены во время выполнения, переходные или нет, не имеет значения для времени выполнения. Учитывая это, ваше утверждение о рекурсии не имеет смысла для меня. –

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