21

私はMavenを数か月使用しており、概念的にも実際にも Maven がどのように機能するかについてはかなり満足しています。

また、 Buckminsterをかなり広範囲に調べました(ただし、まだサンプルを実行することはできていません)。ドキュメントが貧弱です。たとえば、Build Automate や Deploy などの用語を使用していますが、デプロイについてはまだ何も見ていません。段階的な移行は、ほのめかされているが議論されていない別のトピックです。

Maven と Buckminster の両方で、依存関係を指定し、一般的にビルド、テスト、および場合によってはデプロイのプロセスを管理できます。

どちらも Eclipse と統合されており、(Maven のみを使用していたので) Eclipse ベースのプロジェクトとその依存関係のセットアップと共有を単純化する必要があります。

私が見ることができる主な違いは次のとおりです。

  • 依存関係:

    • Buckminster は、依存関係の Maven リポジトリを参照できることに加えて、ソース リポジトリと独自のタイプのリポジトリに存在する依存関係を指定できます。
    • Buckminster は、依存関係を仮想ディストリビューションにグループ化でき、プラットフォームにも対応しています。ソフトウェアのグループ化は、他の依存関係を参照してそれらをグループ化する pom を使用して、Maven で確かに可能であるように思われます。

  • 建てる

    • Maven は、レイアウトに基づく暗黙的なビルド システムを使用します。デフォルトのプロジェクトを作成し、期待される場所に配置し、maven でビルド、テスト、および jar を作成するのは非常に簡単です。同時に、暗黙的であることは制約にもなり得ます。Maven のやり方に慣れる必要があります。
    • Buckminster - Buckminster が何をどのように構築するかをどのように決定したかは、私には明らかではありません。これは、同じことを行うための eclipse プロセスと一致するように思われます。Buckminster も ant の使用を許可していますが、これが要件であるかどうかは明らかではありません。少なくとも、ライフサイクルの良し悪しの定義が少なく (未?)、柔軟性が高くなります。
    • どちらのツールもヘッドレス ビルドを可能にしますが、バックミンスターにはもう少し多くの荷物が必要になる場合があります。

  • プラグイン

    • Maven には、コード生成からテスト用の組み込みサービスの実行まで、さまざまな種類の自動化のライフサイクルのすべてのフェーズに対応する非常に広範なプラグイン セットがあります。
    • Buckminster には、同じプラグインの概念がないようです。読み手と俳優がいますが、同じ役割を果たしているようには見えません。Buckminster は、ant で利用可能なプラグインの広範なセットにアクセスできる必要があります。ant アクションを残りの Buckminster プロセスとシームレスに統合できるかどうかは明確ではありません (これは maven ant プラグインの問題でもあります)。

  • 展開

    • Maven には、ソフトウェアのディストリビューション (アセンブリ) を生成し、それらを移動する (ワゴン) ためのプラグインが多数あります。バックミンスターはこれらすべてを Ant から取得しますか?

  • 複雑

    • バックミンスターのさまざまなスキーマは、CPEC、RMAP、MSPEC などの間で非常に複雑になる可能性があります。
    • Maven は、大規模なマルチモジュール プロジェクトでは複雑になる可能性がありますが、構成に関してはいくぶん単純です。Maven には、新しいプロジェクトを簡単に作成するためのアーキタイプもあります。

  • ドキュメンテーション

    • 彼らは両方とも悪いです。;-)
    • Buckminster はドキュメントに関して非常に浅いです。十分な例がありません。
    • Maven プラグインは、ドキュメントが非常に貧弱である傾向があり、正しく実行するのが難しくなっています。

私の観点からすると、Buckminster でやりたいことのほとんどは、Maven で実行できます。バージョン管理からの「実体化」はプラスですが、組織内の開発者は、固定バージョンを提供するだけでなく、Maven スナップショットをリポジトリに公開して相互に共有できます。

Maven ライフサイクルの制約から、より多くの柔軟性と自由があるように見えます (クリーンアップのための事後テストのような別のフェーズを追加したいと思ったことはありませんか? コアでそれを行うのを待つ必要があります)。

私は何が欠けていますか？Buckminster には、複雑化する価値のある重要な機能がいくつかありますか?

上記の非常に不正確なステートメントはありますか?

4

7 に答える 7

10

いくつかの説明。

  • 依存関係

    Buckminsterには独自のリポジトリタイプはありません。これには、MavenPOMなどの既存のメタデータをバックミンスターが理解できるモデルに変換する検出メカニズムがあります。このメタデータは、他の方法で取得できない場合は、XMLファイルとしてそのまま追加できます。

  • 建てる

    Buckminsterは、EclipseIDEと同じ方法で何を構築するかを決定します。さらに、マニフェスト、build.properties、plugin.xmlなどの既知のアーティファクトから情報を抽出し、Buckminsterperformコマンドを使用して明示的にトリガーできるモデル内のアクションに変換します。

    私は、バックミンスターがヘッドレスビルドのためにより多くの荷物を運ぶとはまったく確信していません。実際、私はその反対がより一般的だと思います。空のマシンでMavenを使用してビルドすることは、手元のタスクが簡単であっても、非常に多くのコンポーネントをダウンロードすることから始まることがよくあります。

  • プラグイン

    BuckminsterはOSGiに基づいており、Eclipse拡張ポイントを使用して拡張されています。このメカニズムを使用して、新しいタイプのリポジトリ、新しいタイプのアクション、新しい検出メカニズムなどを追加することができます。

  • 複雑

    最小のバックミンスター構成には、1つのCQUERYと1つのRMAPのみが必要です。それらを使用すると、pack200で署名および処理される任意のサイズの完全なp2更新サイトを構築できます。機能やバンドルにファイルを追加する必要はありません。「バックミンスター化」する必要はありません。そのため、Mavenの構成が簡単であることに同意するかどうかはわかりません。

RolandとZoltánがすでに述べた利点に加えて、バックミンスタービルドは真のワークスペースビルドであるため、.projectファイルで宣言されているすべてのビルダーを活用することを付け加えたいと思います。ここではいくつかの例を示します。

  • PDEマニフェストビルダー-マニフェスト、プロパティファイルなどから警告とエラーを生成します。
  • PDEスキーマビルダー（拡張ポイントスキーマでも同じ）
  • 他のすべてのビルダーは、Eclipseビルド構造用に作成されました。これには、XMLスキーマ検証ビルダー、Javaスクリプトビルダー、およびその他多くのビルダーが含まれます。
Mavenはそれらの大多数に対応していると確信しています。Buckminsterのポイントは、追加のビルドシステムを維持する必要がないということです。IDEワークスペースで機能するものは、ヘッドレスでも機能します。

于 2010-04-28T15:41:10.140 に答える
7

Mavenは、レイアウトに基づく暗黙的なビルドシステムを使用します。デフォルトのプロジェクトを作成し、期待される場所に物を置き、Mavenでjarをビルド、テスト、作成するのは非常に簡単です。同時に、暗黙的であることも収縮する可能性があります。Mavenが物事を行う方法と一緒に暮らす必要があります。

実際、Mavenのどこに物を置くかを明示的に指定できます。デフォルトの場所はまさにそれであり、デフォルトであり、簡単に上書きできますが、正当な理由はめったにありません。

バックミンスター-バックミンスターが何を構築するか、どのように構築するかを決定する方法は私にはわかりません。これは、同じことを行うための日食プロセスと一致するように思われます。Buckminsterはantの使用も許可していますが、これが要件であるかどうかは明らかではありません。少なくとも、ライフサイクルは良いか悪いかについて定義されていない（un？）ので、柔軟性が高くなります。

Mavenは、簡単に上書きされる賢明なデフォルトの哲学に従う傾向があると思います。

Mavenは、大規模でマルチモジュールのプロジェクトでは複雑になる可能性がありますが、構成に関してはやや単純です。Mavenには、新しいプロジェクトを簡単に作成するためのアーキタイプもあります。

Mavenの真の強みは依存関係の管理にあり、これは複数のサブプロジェクトを持つ複雑なプロジェクトで特によく輝く傾向があります。サブプロジェクトの階層を定義して、それを機能させるのは非常に簡単です。

ドキュメント：どちらも悪いです。;-)

それに異議を唱えることはできません！

于 2009-02-24T01:00:31.890 に答える
7

Buckminster Download ページから入手できる PDF 形式の Buckminster Book があります。250 ページを超えるドキュメントがあり、紹介と詳細なリファレンス ドキュメントの両方が含まれています。

ここからダウンロードしてください: http://www.eclipse.org/downloads/download.php?file=/tools/buckminster/doc/BuckyBook.pdf

于 2010-04-28T14:03:05.210 に答える
5

Buckminster を使用する最大の利点は、OSGi バンドルまたは Eclipse プラグインをコンパイルする場合です。PDE ビルド インフラストラクチャを再利用できるため、manifest.mf/plugin.xml ファイルに既に存在するすべての種類のバージョン管理情報を処理できます。Mavenを使用する場合、この情報を複製する必要があります（AFAIK）。Eclipse プラグインを開発しておらず、すでに Maven に精通している場合、特に学習曲線が急峻であることを考えると、Buckminster を使用しても実際のメリットはありません。一方、Eclipse プラグインをビルドする場合は、すぐに使用できる優れたサポートが提供されます。

Buckminster を拡張するには、新しいリーダー (他の場所からソースを取得するため) または新しいアクター (ビルド ステップを提供するもの - これらのアクターは Maven または Ant を再利用できるため、追加機能を提供できます) を作成します。

于 2010-03-09T15:31:24.100 に答える
3

なぜ誰もTychoについて言及しなかったのだろうか。Tycho はEclipse プロジェクトとして提案されており、現在はインキュベーション段階にあります。

バックミンスターと仲良くしようとしましたが、今度はティコに目を向けます。これには次の理由があります。

  • 前述のように、バックミンスターのドキュメントは本当に悪いです。
  • 実際、バックミンスターの例を実行したことは一度もありません。
  • 私はMavenを知っており、ドキュメンテーションはバックミンスターよりも優れています。
  • ビルド サーバー (Jenkins) を使用したいのですが、Maven の統合は非常に優れています。

現時点では Tycho の経験はありませんが、有望なようです。

于 2011-07-12T12:27:45.283 に答える
2

バックミンスターについての私の (非常に限られた) 理解は、一言で言えば、チーム メンバー間で一連のプロジェクトの Eclipse プロジェクト構成をバージョン管理および共有するためのシステムであるということです。依存関係を管理するという点で Maven と重複しているように見えますが、これらは Eclipse プロジェクト レベルの依存関係であり、Java の依存関係ではないと思います。

個人的には、ビルド プロセスを Eclipse やその他の IDE に結び付けたくありません。IDE やその他の GUI ツールを必要とせずに、コマンド ライン ツールからフル ビルドを実行できることには、多くの利点があります。

無料の O'Reilly ブックMaven: The Definitive Guideは見事に書かれており、Maven ドキュメントのギャップを実際に埋めています。

于 2009-02-26T04:41:12.780 に答える
0

バックミンスターのドキュメントが不足しているため、私はBuckminster/Hudson を使用したビルディング プロダクトの例を作成しました。これは始めるのに役立つかもしれません.Jenkinsでも動作します.

Ralf のチュートリアルを使用して、トピックの概要を把握しました。

ターゲット プラットフォーム

ハドソンとバックミンスターのセットアップ方法は、ラルフのチュートリアルで読むことができます。ちょっとしたヒントですが、OutOfMemoryErrors を防ぐには、Buckminster インストールの「追加パラメーター」に -Xmx1024m を追加してください ( トラブルシューティングのヒント Hudson out of memoryを参照してください)。

他のジョブ用にターゲット プラットフォームを公開するための別のフリー スタイル ジョブがあります。「ソースコード管理」セクションで、ターゲット定義 (私の場合は ch.scodi.client.site) を含むフィーチャーをチェックアウトします。
実際にターゲット定義を解決するために、次のコマンドを使用してビルド ステップ「Run Buckminster」を追加しました。

importtargetdefinition -A '${WORKSPACE}ch.scodi.client.site/TargetDefinition.target'

ビルド後のアクションで、「Eclipse ターゲット プラットフォームをアーカイブして公開する」をチェックし、 .metadata/.plugins/org.eclipse.pde.core/.bundle_poolパスとして追加しました。

TargetDefinition がディレクトリの場所を解決できないことを考慮してください。私のターゲット定義には、springsource リポジトリからのバンドルを含むディレクトリの場所がありました。
マテリアライゼーション中に rmap ファイルを使用してバンドルを取得しようとしましたが、問題が発生したため、それらのバンドル用の独自の更新サイトを作成し、このサイトをターゲット定義に追加することにしました。詳細については、
http ://www.eclipse.org/forums/index.php?t=msg&th=164508&start=0& を参照してください。

製品の構築

ターゲット定義ジョブが実行されたら、製品の構築を開始できます。
これは非常に簡単です。SVN からソースをチェックアウトする方法については、Ralf のチュートリアルを参照してください。
サーバー製品とクライアント製品のそれぞれに、Integration、Nightly、Release の 3 つの異なるビルドがあります。
ビルドごとに、プラグイン修飾子は異なる必要があります (例: I20100326-2、N20100326、R20100326-01)。これを達成するために、流れるプラグインをインストールしました:
http://wiki.hudson-ci.org/display/HUDSON/Version+Number+Plugin
統合ジョブで、「フォーマットされたバージョン番号を作成する」を選択し、「バージョン」という名前を付けますこのようなものI${BUILD_YEAR, XXXX}${BUILD_MONTH, XX}${BUILD_DAY, XX}-${BUILDS_TODAY}をフォーマットとして使用します。

最終的にクライアント製品をビルドするために、Buckminster ビルド ステップを追加し、以前に公開されたターゲット プラットフォームを選択し、コマンドとして次を使用しました。

import '${WORKSPACE}source/scodi-rcp/features/ch.scodi.client.site/site.cquery'

build

perform -D target.os=* -D target.ws=* -D target.arch=* -D
qualifier.replacement.*=${version} ch.scodi.client.site#site.p2.zip
perform -D target.os=win32 -D target.ws=win32 -D target.arch=x86
ch.scodi.client.site#create.product.zip perform -D target.os=win32 -D
target.ws=win32 -D target.arch=x86_64
ch.scodi.client.site#create.product.zip

これは、 Buckminster /Eclipse にフォーマットされたバージョンを修飾子として使用するように指示し、バンドルで定義されている必要がある、 qualifier.replacement.*=${version}このような名前のプラグインになります 。com.softmodeler.model_1.0.0.I20100325-3.jarBundle-Version: 1.0.0.qualifiermanifest

http://flaviodonze.blogspot.ch/2010/03/building-products-with.html

于 2016-09-02T11:37:50.817 に答える