Ivy не может разрешить область зависимости, которая является зависимостью транзитивной зависимости.

Question

Я добавляю зависимость (назовем ее как A) в ivy.xml, которая имеет файл pom в центральном центре maven. Ivy использует ibiblio для разрешения зависимостей maven. Зависимость (A), которая добавляется к ivy.xml, имеет транзитивную зависимость (B). Пока все хорошо. Зависимость (C) транзитивной зависимости (B) не может быть решена плющом.

Я определил в ivy.xml так:

<dependency org="Z" name="A" rev="0.6-SNAPSHOT" conf="*->default"/> 

В пом файла B, C, определяется как в компиляции и тестирования областей, как показано ниже:

<dependency> 
     <groupId>X</groupId> 
     <artifactId>C</artifactId> 
    </dependency> 
    <dependency> 
     <groupId>X</groupId> 
     <artifactId>C</artifactId> 
     <type>test-jar</type> 
     <scope>test</scope> 
</dependency> 

Когда я выглядеть XML-файл в, который разрешен плюща в кэш-файле плюща (~/.ivy2/кэш/X/C/плющ-0.98.8-hadoop2.xml), это выглядит следующим образом:

<dependency org="X" name="C" rev="0.98.8-hadoop2" force="true" conf="test->runtime(*),master(*)"/> 
<dependency org="X" name="C" rev="0.98.8-hadoop2" force="true" conf="test->runtime(*),master(*)"> 
    <artifact name="C" type="test-jar" ext="jar" conf="" m:classifier="tests"/> 
</dependency> 

По этой причине плющ не может правильно определить области C. Для записи у меня нет прав на изменение файлов pom, поскольку они являются сторонними проектами. Как я могу это исправить?

Answer 1

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

• «компилировать» и «тест» мишень выпускающие отдельные вызовов к решимости задаче
• Каждый плагин также вызывает задачу разрешения плюща
• Сложная логика для поддержания классов классов. Может быть упрощено с помощью заданий и конфигураций плюща cachepath.
• Строительные плагины не управляются плюща (Sonar, затмение, крыса)

Я начал реорганизовывать сборки, но должен был остановиться, когда я понял, что я не понимаю, отношения между главным Nutch артефакта и плагины ... (я обнаружил NUTCH-1515 трудный путь ... большое время-waster В корневом плагине отсутствуют зависимости).

Я также заметил выпуск NUTCH-1371, призывающий к удалению плюща. Это было бы сложным рефакторингом без существенных изменений в текущей кодовой базе. Я подозреваю, что это будет многомодульная сборка с каждым плагином, перечисляющим его собственные зависимости.

В заключение, эта работа не отвечает на ваш вопрос, но я подумал, что мне нужно хотя бы документировать результат анализа нескольких часов :-) В свете NUTCH-1371 Я не знаю, будет ли в вашем проекте терпимый пересмотр репликации плюща ?

Рефакторинг плющ

Здесь следует, что я достиг до сих пор:

• Private "development" fork of the nutch project
• Diff with trunk

Преимущества:

• SINGL е плющ отчет, показывающий все конфигурации (New ivy-resolve target)
• Нового механизма для установки плюща (New ivy-install target)
• пути к классам управляются с помощью конфигураций плюща (см использования плюща cachepath задачи и configurations in ivy file)
• Затмения, сонара и крыс ANT задачи автоматически устанавливаются с помощью плюща (плагин Eclipse примечателен тем, что использует packager resolver для загрузки и извлечения баннера из архива tar).

Воздействия следующих Nutch вопросы

• NUTCH-1881: Этот новый подход снимает решимость тест и решить, по умолчанию цели и управляет использование плюща к классам вместо $ {build.lib.dir}
• NUTCH-1805: Может легко настроить отдельную конфигурацию для целевой задачи с ее собственными зависимостями.
• NUTCH-1755: Я думаю, что это один фиксируется путем присвоения имени к build.xml (см: diff)