2009-10-02 2 views
4

Мне нужно запланировать подкомпонент мула-транспорта-jms мула для этой ошибки (http://www.mulesoft.org/jira/browse/MULE-3983). «Исправить» просто, но меня раздражает развертывание исправленного компонента на моем локальном репозитории maven (управляется Nexus), и он продолжает хорошо играть со всеми остальными компонентами мула.Как скопировать подкомпонент в управляемую maven инфраструктуру?

Я хочу, чтобы наклеить мои недавно исправленные mule-transport-jms как исправленные версии 2.2.1, а также на мои компоненты esb, а также другие компоненты мула (например, mule-core), которые все еще установленный в версии 2.2.1. Поскольку мулы транспортно-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-исправленной ломает все, добавив версию тега, так что она выглядит следующим образом:

<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> 

брейки целый ряд зависимостей, которые предположительно объявлены в ПОМ родителя (не упоминать об этих неудачных зависимостях в любом месте этого проекта).

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

Любые мысли?

+0

После того, как я немного поиграл с этим, я пришел к выводу, что любое перемещение maven слишком сильно похоже на тяжелую работу - это может сосать, но я решил просто позволить маршрутизацию ретрансляции nexus позаботиться о доставке исправленного jar под тем же GAV, что и незагруженный. Спасибо за предложения, хотя ... – omeyn

ответ

1

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

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

1

Применение вашего патча и восстановление всего 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 a nd повторите команду maven для их создания.

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

0

Это действительно вопрос о maven, а не Mule's. Правильный подход заключается не в том, чтобы иметь «взломанную» версию, а скорее в другой версии в репо с квалификатором (точно так же, как с «исправленным»). Далее осмотрите транзитивные зависимости в Maven (использование МВН зависимость: дерево & зависимость: цели списка) и убедитесь, что:

  1. Модифицированная зависимость объявлена ​​и используется, и
  2. оригинальный, не исправлен зависимость без из графика зависимости.
Смежные вопросы