多くの場合、1つまたは別のアセンブリシステムの宣言型と手続き型で、誰もが同じことを理解していないことを確認する機会がありました。 アセンブリツールの主な利点は、多くの場合、便利な言語でアセンブリアルゴリズムを作成できることです。 DSLが必要です。
段階的に、このDSLはgroovyに基づいています。 sbtはロックを使用し、leiningenはClojureを使用し、Antはxmlを使用します（ちなみに、完全に無関係です）。 JavaScriptベースのビルドシステムを思い出すのは簡単です。 誰もが彼に近い言語で収集します。 また、新しいツールは、たとえばKotlinで作成されています。
残念ながら、DSLの存在は宣言的な意味ではありません。 むしろ、反対。 その結果、gradleプロジェクトはpom.xmlなしでは完全に生きることができません。 これは冗談ですが、多くの真実があります。 ここを見てください：それはリポジトリです 。
ここには何がありますか？ はい、はい、それはpom.xmlです、それが最もです。 build.gradleはどこにありますか？ しかし、彼ではありません。 分かりますか？ 彼はここにいません 。
つまり、gradleを使用して収集された、 組み立てられたプロジェクトについて提供されるすべてのメタデータは、Mavenメタデータのみで構成されています。
これはあなたを驚かせますか？ 私は全然違います。 私の意見では、gradle、sbt、leiningen、および他の多くのツールは、他の製品からアクセス可能な方法でメタデータをほとんど（またはまったく）提供します。
それらは本当に自分自身だけに見え、組み立てプロセス内からのみ見えます。 ビルドスクリプトがグルーブコード（Clojure、rock、javascript）であるという理由だけで。 IDEがそれらをあまりサポートしていないのはそのためです（スクリプトがxmlであるmavenやantと比較して）。 そこで何が起こっているのかを理解するには、実行する必要があります。 内部にgradleが必要であり、gradleが必要な情報をIDEに返す必要があります。
自分の宣言性をどのように確認し、なぜそれが必要なのですか？ 実例として、2つのプロジェクトと1つのApacheのプロジェクトを提供します。
- Apache Karafから始めましょう。 sshコンソールでは、モジュールインストールコマンド（OSGIバンドル）を使用できます。 このコマンドは、mavenリポジトリーのモジュール座標： bundle：install mvn：groupId / artifactId / versionのみを使用します。 同時に、maven karaf自体には含まれていません-ボンネットの下には、エーテルのみに加えて、ラッパー（Pax URL）があります。
- かつてJythonで同様の構造を実装しましたが、Weblogic内で機能していました。 同じエーテルとWLST APIが使用されました。 これにより、JavaEEコンテナにインストールされたモジュールを自動的に更新し、リポジトリで新しいバージョンを探すことができました。
繰り返しますが、mavenは設計に含まれていません。 リポジトリ、Aether、およびpom.xmlが使用されました。これらは、META-INFモジュールにパックされています。
- そして最後の例。 私の練習では、1つのMavenプラグインがあり、SVNを初期データとして使用して、プロジェクトの変更についてフォルダーとファイルをスキャンし、それらをバグトラッカーと比較し、どの収集されたアーティファクトをリリースに含めるべきかを決定してデプロイします。
これからどのような結論を導き出すことができますか？
まず、プロジェクトの説明（私の場合は常にpom.xmlでした）では、十分に開発された言語で作業することが必要な場合があります。 プロジェクトが最初に設計されたビルドツールである必要はありません。
第二に、RESTの原則に従ってリポジトリが正しく設計されていれば、httpサーバーを除き、特別なソフトウェアを使用する必要はありません。 プロジェクトのすぐ上にメタレベルのデータのみが必要です（使用可能なバージョンのリストなど）。
第三に、インフラストラクチャの重要な部分、この場合はプラグイン自体が通常のアーティファクトであり、同じリポジトリにあり、特定のプロジェクトとはまったく関係がないことが非常に便利です。
これは私が宣言的アプローチと呼んでいるものです。 プロジェクトがあり、それらの多くがあります。 それらはたまたま、収集されたアーティファクトの形で、VCSなどの場所にあり、1つのツールだけでなく、さまざまなツールで処理できます。 プロジェクト記述子は、処理のための標準的で便利な形式の単なるファイルです。 アーティファクトリポジトリも、標準化された形式+シンプルなREST APIです。 そして、あなたにとって便利なDSL上のアセンブリロジックは、別々にあります。 記述子自体に必要であり、リポジトリに必要です。
これをどうやってやるの？ 本質的に、Mavenを基礎とする場合、既存のxmlはプラグインとカーネルJavaデータモデルのシリアル化された表現であり、柔軟性がないため、プラグイン、その設定などに関して十分な柔軟性がありません。 開発者がプロジェクトに関するデータを必要としないと判断した場合、プロパティの形式のキー値オプションのみがあります。
しかし、任意の、しかし通常の構造、例えば、RDFタイプの（必ずしもそれだけでなく）何かを行う必要があります。
RDF形式のプロジェクトの説明により、データベース内での検索などの便利なことがすぐにできます（つまり、メタデータの観点からリポジトリはSPARQLエンドポイントになり、検索クエリに応答できます）。 また、プロジェクトに関連して同じクエリを作成できます。
これは真のポリロットメイベンになります。 さらに、これは、既存のインフラストラクチャ内であっても、実行可能なように見えます。