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. ユーザーは検出された更新を選択してインストールします。

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