4

I need to patch the mule-transport-jms subcomponent of mule for this bug (http://www.mulesoft.org/jira/browse/MULE-3983). The "fix" is straightforward but what is vexing me is deploying the patched component to my local maven repo (managed by Nexus) and having it continue to play nicely with all the other components of mule.

What I want is to label my newly patched mule-transport-jms as version number 2.2.1-patched, and have my esb components depend on that as well as the other mule components (eg mule-core) which are still set at version 2.2.1. Because the mule-transport-jms pom reads (in part) like this:

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

there are many interdependencies that rely on the version being 2.2.1. Changing the parent version (as shown above) to 2.2.1-patched breaks everything, adding a version tag so that it looks like this:

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

breaks a number of dependencies that are presumably declared in the parent's pom (no mention of those failing dependencies anywhere in this project).

I can probably hack Nexus to always retrieve my patched version when mule-transport-jms v2.2.1 is requested, but that's dirty. I'd really like to be able to just specify exactly which GAV to use in my client pom, and when it's time to upgrade (assuming the bug gets properly fixed in v3.0, say) just update my client pom to point to version 3.0.0 and my patched, 2.2.1 jar just gets ignored, and no hacking of nexus is required. Obviously I'd also like to avoid checking out every mule component and updating their poms and redeploying them all as 2.2.1-patched.

Any thoughts?

4

3 に答える 3

1

mule-transport-jmspomのパッチを適用したバージョンへの依存関係を明示的に設定できるはずです。標準バージョンよりも近いため、標準バージョンをオーバーライドし、あなたのバージョンが使用されます。依存関係をプラグイン宣言に追加する必要がある場合があります。このブログ投稿では、依存関係のあるプラグインを構成する方法について説明します。

これでうまくいかない場合は、パッチを適用したバージョンをどのように使用する必要があるかについて、もう少し情報を提供していただけますか?

于 2009-10-02T13:47:58.707 に答える
1

パッチを適用し、全体mule-transportをバージョンとして再構築すること2.2.1-patchedが、おそらく最良の解決策です。しかし、これがどれだけの労力 (つまりビルド時間) を表しているかはわかりません。

mule-transport-jmsもう 1 つのオプションは、モジュールのパッチ バージョンとそれに依存するプロジェクトのみをビルドすることです。これらのプロジェクトを簡単に見つけるために、リアクターを使用して依存プロジェクトを特定できます。

  • 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 コマンドを繰り返してビルドします。

これがビルド全体よりも時間がかからないかどうかはわかりません。

于 2009-10-02T13:58:42.927 に答える
0

これは、Mule の質問ではなく、実際には Maven の質問です。正しいアプローチは、「ハッキングされた」バージョンではなく、修飾子を使用してレポ内の別のバージョンを使用することです (「パッチを適用した」場合と同様)。次に、maven の推移的な依存関係を検査し (mvn 依存関係: ツリーと依存関係: リストの目標を使用)、次のことを確認します。

  1. パッチが適用された依存関係が宣言され、使用されている。
  2. パッチが適用されていない元の依存関係は、依存関係グラフから除外されます。
于 2010-01-19T16:38:36.637 に答える