26

受け入れられた回答に関する注意:強力な状況証拠があるため、回答を受け入れました。とはいえ、これは状況証拠ですので、慎重に考えてください。

ユーザーがライフサイクル フェーズではなく、プラグインの目標を実行したときにプラグインをトリガーするにはどうすればよいですか? (これは以前にも尋ねられましたが、答えはライフサイクル フェーズを使用することでした。)

適切な例: -SNAPSHOT サフィックスを除いた名前から現在のバージョンのブランチを生成するrelease:branchために呼び出す必要があります。これは私が持っているもので、開発者はプロファイルをアクティブにしてフェーズを呼び出す必要があります。開発者は単に を呼び出す必要があり、これにより実行が開始されます。Gitflow との結婚のようなものです。regex-pluginverifyrelease:branchregex-plugin

<profile>
    <id>Release Branch</id>
    <build>
        <plugins>
            <!-- On validate, compute the current version without -SNAPSHOT. -->
            <!-- Put the result in a property. -->
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>build-helper-maven-plugin</artifactId>
                <version>1.7</version>
                <executions>
                    <execution>
                        <phase>validate</phase>
                        <goals>
                            <goal>regex-property</goal>
                        </goals>
                        <configuration>
                            <value>${project.version}</value>
                            <regex>^(.*)-SNAPSHOT$</regex>
                            <replacement>$1</replacement>
                            <name>project.unqualifiedVersion</name>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <!-- Also on validate, run the branch plugin, and use -->
            <!-- the non-SNAPSHOT version thus computed in the branch name. -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-release-plugin</artifactId>
                <version>2.3.2</version>
                <executions>
                    <execution>
                        <phase>validate</phase>
                        <goals>
                            <goal>branch</goal>
                        </goals>
                        <configuration>
                            <branchName>release/${project.unqualifiedVersion}</branchName>
                            <updateWorkingCopyVersions>true</updateWorkingCopyVersions>
                            <updateBranchVersions>false</updateBranchVersions>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</profile>

その意図はrelease:branch、現在のスナップショット バージョン (たとえば、1.0.5-SNAPSHOT) を新しいブランチに移動することです。新しいブランチには、バージョンにちなんだ名前を付ける必要がありますが、余分な-SNAPSHOTサフィックスは付けません ( 1.0.5)。次に、現在のブランチは新しいスナップショット バージョンを取得する必要があります (1.1.0-SNAPSHOTではなく1.0.6-SNAPSHOT、リリース1.0.xにホットフィックスの余地が必要なため、ブランチ用に予約します) (次のスナップショット バージョンの自動計算はまだ把握していません)したがって、上記の Maven 構成を で実行する場合validateは、プロンプトで入力する必要があります)。

4

2 に答える 2

8

これまでに提示された証拠は、かなり状況に応じたものです。私は自分でいくつかの調査を行ったので、ここで共有することをお勧めします。以下は、同じ「不可能」であるか、代替の構成要素です。

jetspeed:mvn プラグイン--- 指定された一連のプラグインを実行します。実行する構成は、システム プロパティによって変更できます。IDE 統合に関する懸念事項

プラグインの実行前に目標を実行する (StackOverflow) --- カスタム Mojo のコンテキストで同じ質問に回答

Mojo に他のゴールを実行させる (StackOverflow) --- ここでも、カスタム Mojo のコンテキストから

デフォルトの Mojo 実行の構成--- Mojo の実行方法を説明する Maven ページ - より多くの状況証拠

ゴール実行前のフェーズのトリガー (StackOverflow) --- 私の問題に対するラウンドアバウトの解決策、残念ながら否定的な回答

興味深い: Ant プラグイン開発ガイド--- 私にとっては魅力的です。カスタム プラグインを作成する必要がありますが、すべて Ant + Maven 構成であり、コンパイルするコードがないためです。おそらく参入障壁が低い

並列ライフサイクルの作成--- ライフサイクルの内容を Gitflow 動詞を使用する場所まで完全に制御できるため、魅力的なアプローチです。IDE がこれをどのように統合するかは不明です。学習曲線と採用障壁の懸念が存在する

于 2013-05-08T04:39:29.540 に答える