Eclipse 更新ポリシー制御

「Eclipse 更新」では、ユーザーは、現在インストール済みのフィーチャーの更新の検索 することができます。 インストールされているフィーチャーごとに、「更新」は組み込み URL を使用してリモート・サーバーと接続し、新規のバージョンを検索します。 更新があると、Eclipse はユーザーがインストール手順を開始できるようにします。 ダウンロード、インストール、およびプラットフォームの再始動の後に、新規フィーチャー・バージョン を使用することができます。

同じ Eclipse ベースの製品 (一般的に市販の製品) に多数のユーザーがいる会社では、 このモデルからいくつかの問題が生じる可能性があります。

  1. 非常に大規模な製品 (例えば、500+ プラグイン) の更新はやはり大規模になります。 IT サポート・チームにとって、何百人もの開発者が個々のマシンにそれぞれ 500 メガの更新をダウンロードするというアイデアは好ましくないでしょう。 帯域幅の瞬断のほかにも、このような大規模なダウンロード要求では障害が発生する可能性があり、 結果として試行が繰り返され、開発者のダウン時間が増加します。
  2. 開発者が直接インターネットから更新をダウンロードすることを明らかに望まない会社もあります。 例えば、ローカル・サポート・チームをセットアップしても、プロバイダーの更新サイトで既に使用可能な製品のバージョンに関する要求を処理する準備ができていない可能性があります。 社内で承認済みのリストに、更新やフィックスを制限することもあります。 理想としては、LAN 上に (ファイアウォールの後ろに) プロキシー更新サイトをセットアップして更新を実施することになるでしょう。
  3. 上記のように一度プロキシー・サイトに更新が設定されると、管理者は更新が使用可能であることを ユーザーに知らせる方法が必要となります。

2. レスキューに対する更新ポリシー 

2.1 ローカル (プロキシー) 更新サイトの作成のサポート

製品管理者が行うべき最初のステップは、会社の LAN (ファイアウォールの後ろ) と接続されたサーバー上にローカル Eclipse 更新サイトをセットアップすることです。 更新サイトは、会社がその時点で適用したいと思っている更新に関連したフィーチャーおよびプラグインのみを含むので、 インターネット上の製品の更新サイトのサブセットになります。 技術的には、このサイトは、site.xml、フィーチャー、およびプラグインのアーカイブを持つ 通常の Eclipse 更新サイトになります。

管理者がこのサイトを構成するには、以下の 2 つの方法があります。

  1. 製品サポート・チームは、この特定の目的のためにすぐに使用可能な更新サイトの Zip ファイルを作成します。 管理者は、選択したツールを使用して、製品サポート Web ページから Zip ファイルをダウンロードし、ローカル・サーバーで unzip します。 この方法は、最新の再始動可能なダウンロード・マネージャー (接続に問題が生じた場合にダウンロードしなかったところをピックアップできる) を必要とする非常に大きな Zip ファイルの場合に有効です。
  2. Eclipse 更新は、リモート更新サイトを完全にミラーリングするツールを提供するか、 または管理者が更新とフィックスを選択してダウンロードできるようにします。 このミラーリング機能は、完全に自動化され、管理者のタスクを非常に単純化するものですが、 更新ネットワーク接続サポートに依存します。

2.2 共通更新ポリシー制御

フィーチャーには、マニフェスト内に組み込まれた更新サイト URL があるので、 フィーチャーは、管理者によってセットアップされたローカル更新サイトについては認識しません。 したがって「リダイレクト機能」を提供することが重要になります。更新ポリシー・ファイルを作成し、 検索時にそのファイルを使用するように「更新」を構成することで、Eclipse 製品に対して この設定および他の更新ポリシー設定を設定することができます。

このファイルでは、XML フォーマットを使用し、任意の名前を付けることができます。 ファイルは、「更新ポリシー」フィールド内の「設定」>「インストール/更新」 で設定できます。 テキスト・フィールドはデフォルトでは空です。 ユーザーは、更新ポリシー・ファイルの URL を設定することもできます。 このファイルはローカル管理者によって管理され、すべての製品インストールで共用されます。 共用は 2 つの方法で達成されます。

ポリシー・ファイルは以下の DTD に準拠しなければなりません。

<?xml encoding="ISO-8859-1"?>

<!ELEMENT update-policy (url-map)*>
<!ATTLIST update-policy
>

<!ELEMENT url-map EMPTY>
<!ATTLIST url-map
    pattern    CDATA #REQUIRED
    url        CDATA #REQUIRED
>

url-map

このエレメントは、フィーチャー・マニフェストに組み込まれた更新 URL をオーバーライドするために使用されます。 新規更新を探すとき、Eclipse 検索は (もしあるならば) 更新ポリシーを確認し、 マッチング・フィーチャー接頭部の「url-map」が指定されているかどうかをチェックします。 一致が検出された場合は、組み込み URL の代わりに、マップされた URL が使用されます。 このようにして管理者は、ファイアウォールの後ろにあるローカル・サーバーの更新を検索するように、Eclipse を構成することができます。 一方、「Eclipse 更新」によってインストールされたサード・パーティーのフィーチャーは、 デフォルトのメカニズムを使用した更新を続けます (ポリシー内に一致を検出できないため)。

幾つかの「url-map」エレメントがファイルの中に存在することがあります。 特定度を小さくしたり、大きくしたりするよう、フィーチャーの接頭部を選択することができます。 例えば、すべての Eclipse 更新をリダイレクトするには、パターン属性は "org.eclipse" になります。 同様に、リダイレクトがフィーチャーごとを基本として要求されている場合、 完全なフィーチャー ID をパターンとして使用することも可能です。

ファイル内のパターンは、潜在的な一致を徐々に狭めていくように選択されます。 その結果、与えられたフィーチャーに対して、複数が一致します。 このケースでは、「一番長いパターンで一致」が使用されます。 例:

<?xml version="1.0" encoding="UTF-8"?>
<update-policy>
	<url-map pattern="org.eclipse" url="URL1"/>
	<url-map pattern="org.eclipse.jdt" url="URL2"/>
</update-policy>

上記のケースでは、URL2 を使用する org.eclipse.jdt 以外は、すべての Eclipse フィーチャーが URL1 から更新されます。

更新ポリシー・ファイルは、翻訳可能なストリングを含んでいないので、特殊な NL 処理を必要としません。 一般的に、それらのファイルでは UTF-8 エンコードを使用する必要があります。

2.3 更新の自動ディスカバリー

全体的なソリューションの 3 番目の部分については、他の トピックで扱いますが、ソリューションの不可欠な部分なので、ここで言及しました。 自動更新は、Eclipse が指定されたスケジュール (始動ごと (デフォルト)、1 日 1 回、1 週間に 1 回、など) で更新の検索を実行できるようにします。

3. 要約

以下がソリューションを構成するステップの完全なシーケンスです。

  1. 管理者は、ローカル製品の更新をホスティングするために、会社の LAN 上でサーバーを割り振ります。 初めは更新サイトを含んでいません。 マシンでは、HTTP サーバーが稼動している必要があります。
  2. 管理者は、サーバーに更新ポリシー・ファイルを設定し、すべてのユーザーに、指定された URL に更新ポリシー設定を設定するよう指示します。
  3. 製品プロバイダーが更新サイトに更新およびフィックスを置いたら、管理者は サポートされる更新をローカル・サーバーにダウンロードします。
  4. クライアントの製品がアップされたときに、スケジュールされた頻度で実行される自動更新は、 ローカル更新をピックアップしてユーザーに通知します。
  5. ユーザーは発見された更新を選択してインストールします。

関連タスク
自動更新スケジューラー

特記事項