Как исправить подкомпонент в управляемой инфраструктурой? - PullRequest
Новая
       18

Как исправить подкомпонент в управляемой инфраструктурой?

4 голосов
/ 02 октября 2009

Мне нужно пропатчить подкомпонент mule-transport-jms мула для этой ошибки (http://www.mulesoft.org/jira/browse/MULE-3983). "Исправить" просто, но меня раздражает развертывание пропатченного компонента в моем локальном репозитории Maven (управляется Nexus) и продолжайте хорошо играть со всеми другими компонентами мула.

То, что я хочу, это пометить мои недавно пропатченные mule-transport-jms как исправленные номера версии 2.2.1, и от этого зависят мои компоненты esb, а также другие компоненты mule (например, mule-core), которые все еще установить на версию 2.2.1. Потому что pom mule-transport-jms читает (частично) так: 

<parent>
    <groupId>org.mule.transports</groupId>
    <artifactId>mule-transports</artifactId>
    <version>2.2.1</version>
</parent>
<artifactId>mule-transport-jms</artifactId>
<packaging>bundle</packaging>
<name>JMS Transport</name>
<description>A Mule transport for Jms Connectivity.</description>

Есть много взаимозависимостей, которые зависят от версии 2.2.1. Если изменить родительскую версию (как показано выше) на 2.2.1-patch, то все разрушится, добавив тег версии, чтобы он выглядел так: 

<parent>
    <groupId>org.mule.transports</groupId>
    <artifactId>mule-transports</artifactId>
    <version>2.2.1</version>
</parent>
<artifactId>mule-transport-jms</artifactId>
<version>2.2.1-patched</version>
<packaging>bundle</packaging>
<name>JMS Transport (ZFP patched)</name>
<description>A Mule transport for Jms Connectivity.</description>

ломает ряд зависимостей, которые предположительно объявлены в pom родителя (нет упоминаний о тех сбойных зависимостях где-либо в этом проекте).

Я, вероятно, могу взломать Nexus, чтобы всегда получать мою исправленную версию, когда запрашивается mule-transport-jms v2.2.1, но это грязно. Я действительно хотел бы иметь возможность просто указать, какой именно GAV использовать в моем клиентском pom, и когда придет время обновляться (при условии, что ошибка исправлена, скажем, в v3.0), просто обновить мой клиентский pom, чтобы он указывал на версию 3.0.0 и мой патч, jar 2.2.1 просто игнорируется, и взлома нексуса не требуется. Очевидно, что я также хотел бы не проверять каждый компонент mule, обновлять их poms и повторно развертывать их как исправленные 2.2.1.

Есть мысли?

Ответы [ 3 ]

1 голос
/ 02 октября 2009

Применение вашего патча и восстановление всей mule-transport как версии 2.2.1-patched, вероятно, является лучшим решением. Но я понятия не имею, сколько усилий (я имею в виду время сборки) это представляет.

Другим вариантом действительно будет создание исправленной версии модуля mule-transport-jms и проектов, которые зависят только от него. Чтобы легко найти эти проекты, вы можете использовать реактор для определения зависимых проектов:

  • если вы используете maven 2.0.x 

    $ mvn reactor:make-dependents -Dmake.folders=mule-transport-jms

  • если вы используете Maven 2.1+ 

    $ mvn -amd -pl mule-transport-jms

Затем обновите pom этих проектов, указав исправленную версию mule-transport-jms, и повторите команду maven, чтобы построить их.

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

1 голос
/ 02 октября 2009

Вы должны иметь возможность явно установить зависимость от пропатченной версии mule-transport-jms в вашем pom. Поскольку он ближе, чем стандартная версия, он переопределит стандартную версию, и ваша будет использована. Возможно, вам придется добавить зависимость в объявление плагина. Это сообщение в блоге описывает, как настроить плагин с зависимостью.

Если это не работает, не могли бы вы предоставить немного больше информации о том, как вам нужно использовать исправленную версию?

0 голосов
/ 19 января 2010

Это на самом деле просто вопрос мавена, а не Мула. Правильный подход состоит не в том, чтобы иметь «взломанную» версию, а в другой версии в репо с квалификатором (точно так же, как вы сделали с «заплатками»). Затем проверьте транзитивные зависимости maven (используйте mvn dependency: дерево и зависимость: список целей) и убедитесь, что:

  1. Пропатченная зависимость объявляется и используется, а
  2. Исходная не исправленная зависимость исключена из графика зависимостей.
...