jboss AS7 をプロジェクトに組み込み、バージョン管理に追加するというアイデアです。さらに、mvn jboss:devserver (mvn appengine:devserver の実行方法と同様) を使用してサーバーを起動する機能を確認するには、独自の archtype を作成することに意味がありますか?
私のクライアントにとって、これにより多くの複雑さが軽減されるため、独自の jboss 構成を作成して、Java プロジェクト開発に取り組むクライアントの C# 開発者と連携できます。変更をローカルで実行するようにローカル マシンをセットアップする方が簡単です。(mvn jboss:devserver) 上記のようなコマンドを使用してください。
このような状況に対処するための理想的な方法は、パッケージングによるものだと思います。クライアントがある種の UNIX サーバー (Linux を含む) にデプロイしている場合、クライアントは既にパッケージ マネージャーを使用してサーバー上のシステム ソフトウェアを管理しています。パッケージ マネージャーには、ソフトウェアをインストール、削除、アップグレードする機能があり、重要なことに、一部のパッケージが依存する他のパッケージをインストールする機能があります。
したがって、JBoss をパッケージ化して、パッケージ マネージャーが JBoss をインストールできるようにし、JBoss への依存関係を指定してアプリケーションをパッケージ化することができます。クライアントがアプリケーション パッケージをインストールすると、JBoss が自動的にインストールされます。
ただし、このプランは、クライアントがある程度のインフラストラクチャをセットアップしている場合にのみ機能します。パッケージマネージャーを備えたシステムを使用する必要があります。パッケージのインストールを管理する方法が必要です (Puppet、Chef、Ansible などの構成管理ツール、またはベンダー独自のものはこれに最適です)。環境内でカスタム パッケージを配布できる必要があります。カスタム パッケージを受け入れるか、パッケージ ビルド スクリプトを受け入れてパッケージ自体をビルドする方法が必要です。
どのような規模のサーバー環境でも、システム管理者はこのようなインフラストラクチャをすべて持つ必要があり、おそらくそうするでしょう。これは、サーバー フリートを管理する上で不可欠だからです。ただし、クライアントがそれを持っていない場合は、セットアップに手間がかかりすぎる可能性があります。
とはいえ、このアプローチの絶対最小限のバージョンは、アプリケーションと JBoss のパッケージ ファイルを電子メールや SFTP などで送信し、システム管理者がそれらを手動でインストールすることです (例: を使用yum localinstall)。これは、JBoss を手動でインストールするよりもはるかに優れているわけではありませんが、正しい方向への一歩です。