5

Java ベースのプロジェクトでは、Maven が非常に優れたパフォーマンスを発揮することがわかりました。この質問から、 Java 以外のプロジェクトも maven モジュールとして後付けできることがわかりますが、さまざまな目的で maven-exec-plugin のみを使用することになります。グーグルでmaven-perl-pluginを見ましたが、それでも散発的な更新を伴う 1.0-SNAPSHOT ですが、確かに非常に有望に見えます。興味のない pom ボイラープレートを書くことから私を解放するこの競合他社を使用した人はいますか?

編集: 実際には、プロジェクトの主要な部分は n 層の Java モジュールであり、非常に小さな perl/python コンポーネント (バックエンド解析用) があり、このエコシステムに適合する場所を探しています。maven-release-plugin を使用してタグ/ブランチの作成とリリース プロセスを実行し、同じコードベースの一部として使用することでバージョン番号の一貫性が得られるなどの利点があります。したがって、perl モジュールに maven の依存関係検索手段を使用するつもりはありませんが (maven-perl-plugin ボーイについて十分に調査していなかったことをお詫びします)、どのような点に留意する必要があるかを知りたいと思いました。そのようなことをする（またはそのようなことが意味をなさない場合）たとえば、モジュール名はどうあるべきか（topLevelModuleName-perl?) および src/main/perl および src/test/perl の下の構造。あるものを別のものに押し付けようとして滑りやすい坂道を下りているかもしれないことは知っていますが、聞いても害はありません:)

4

3 に答える 3

1

現時点では、Dist::Zilla や Module::Build などの確立されたピアとオーバーラップしているように見えるため、依存関係機能に maven-perl-plugin を使用しない傾向があります。誰も編集について実際にコメントしていないので、既存のプロジェクト構造を次のように維持する必要があります

<perl-module-name>
    -lib
    -etc
    -bin

出力アーティファクトとして作成されるtarballを使用してpomファイルを追加する以外は、実際には何も変更しません。

他の提案を自由に投稿してください。

于 2012-07-10T14:20:48.277 に答える
1

それはクレイジーです。Module::Build のような適切なものを使用し、依存関係には CPAN (または cpanm) を使用します。真剣に、Java 以外の場合は、クレイジーなプラグインをロードするために XML をロードする必要があります。Module::Build (または任意のスクリプト) を使用すると、ビルドをプログラムし、その言語で利用可能な任意のライブラリを使用できます (事前に cpanm で取得する必要があるだけです)。

于 2012-07-02T18:18:41.673 に答える
0

このプラグインをざっと見ましたが、プロジェクトを管理するためだけに Java や XML などの依存関係を取り込む意味がわかりません。

実際には、 Dist::Zillaというもっと優れたものがすでにあると思います。プロジェクトのセットアップは簡単で、他のすべてを処理します。dzil new My::ProjectDist::Zilla

Makefile、README、MANIFEST はもう必要ありません。入力するだけでdzil build/test/install/release、プロファイルに従ってすべてが実行されますdist.ini。

また、CPAN からの依存関係が不足している場合は、これを構成に追加すると、cpanminusを新しいワークフローにスムーズに統合できます。

[alias]
    instdeps = install --install-command "cpanm ."
于 2012-07-03T00:44:34.670 に答える