Eclipse 更新ポリシー制御

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

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

  1. 非常に大きな製品 (500+ プラグインなど) の場合、それに対する更新も大きい。 I/T サポート・チームは、多数の開発者が個々のマシンに 500MEG の更新をダウンロードすることはお勧めしません。処理能力への影響以外に、このような大きなダウンロード要求は、失敗し、繰り返し試行して、開発者のダウン時間が増す可能性があります。
  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>

上記の場合、すべての Eclipse フィーチャーは URL1 から更新されますが、URL2 を使用する org.eclipse.jdt は更新されません。

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

2.3 更新の自動検出

自動更新の使用により、Eclipse は、指定されたスケジュール (始動ごと (デフォルト)、1 日 1 回、週に 1 回など) で更新検索を実行します。

3. 要約

以下に、ソリューションを構成するステップの順序を示します。

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

 
Copyright IBM Corporation and others 2000, 2004