Eclipse 갱신 정책 제어

Eclipse 갱신을 사용하여 사용자는 현재 설치된 기능에 대한 갱신을 검색할 수 있습니다. 설치된 각 기능에 대한 갱신에서는 내장 URL을 사용하여 원격 서버에 연결한 후 새 버전을 검색합니다. 갱신이 있는 경우 Eclipse에서 사용자가 설치 프로시저를 시작할 수 있습니다. 플랫폼을 다운로드하여 설치한 후 재시작하면 새 기능 버전이 사용할 준비가 된 것입니다.

동일한 Eclipse 기반 제품(보통 판매용)을 사용하는 사용자가 많은 회사의 경우 이러한 모델에서 여러 문제점이 발생할 수 있습니다.

  1. 매우 큰 제품(예: 플러그인이 500 이상인 제품)의 경우 해당 갱신도 큽니다. I/T 지원팀에서는 수백명의 개발자가 500MEG 갱신을 각자의 개별 시스템에 개별적으로 다운로드한다는 생각을 반기지 않을 수도 있습니다. 대역폭 일치 이외에 이러한 대형 다운로드 요청에 실패하면 반복 시도를 유도하고 개발자의 다운타임을 증가시킬 수 있습니다.
  2. 일부 회사에서는 개발자가 갱신을 인터넷에서 직접 다운로드하는 방법을 좋아하지 않습니다. 예를 들어 제공자의 갱신 사이트에서 이미 사용 가능한 제품 버전과 관련된 요청을 처리할 준비를 못한 상태로 로컬 지원팀을 설정할 수 있습니다. 이들은 갱신 및 수정사항을 내부적으로 승인된 목록으로 제한하려고 합니다. 이론상 LAN(방화벽 뒤에 있음)에 '프록시' 갱신 사이트를 설정하여 제한할 수 있습니다.
  3. 갱신을 위의 프록시 사이트에 설정하면 관리자는 사용자에게 갱신이 사용 가능함을 알리는 방법이 필요합니다.

2. 구분(rescue)으로 갱신 정책

2.1 로컬(프록시) 갱신 사이트의 작성 지원

제품 관리자의 첫 번째 단계는 회사의 LAN(방화벽 뒤에 있음)에 연결된 서버에 로컬 Eclipse 갱신 사이트를 설정하는 것입니다. 갱신 사이트에는 회사가 당시 적용하려는 갱신과 관련된 기능 및 플러그인만 들어 있으므로 갱신 사이트는 인터넷에 있는 제품 갱신 사이트의 서브세트입니다. 기술적으로 이 사이트는 site.xml, 기능 및 플러그인 아카이브가 있는 보통 Eclipse 갱신 사이트입니다.

관리자는 두 가지 방법으로 이 사이트를 구성합니다.

  1. 제품 지원팀은 갱신 사이트의 zip 파일을 이 특정 목적을 위해 즉시 사용할 수 있도록 합니다. 관리자는 선택한 도구를 사용하여 제품 지원 웹 페이지에서 zip 파일을 다운로드한 후 해당 파일을 로컬 서버에 압축 해제하기만 하면 됩니다. 이러한 방법은 재시작 가능한 최신 다운로드 관리자가 필요한 매우 큰 zip 파일에 유용합니다. 이러한 관리자에서는 연결에 문제점이 있는 경우 중단할 위치를 선택할 수 있습니다.
  2. Eclipse 갱신에서는 원격 갱신 사이트를 전체적으로 이중복사하거나 관리자가 다운로드할 갱신 및 수정사항을 선택할 수 있도록 하는 도구를 제공합니다. 이 이중복사 기능은 완전 자동화되었으며 관리자 타스크를 상당히 단순화하지만 갱신 네트워크 연결 지원에 의존합니다.

2.2 공통 갱신 정책 제어

기능에는 Manifest에 내장된 갱신 사이트 URL이 들어 있으므로 이러한 기능에서는 관리자가 설정한 로컬 갱신 사이트를 인식하지 못합니다. 따라서 재지정 기능을 제공하는 것이 중요합니다. 정책 갱신 파일을 작성하고 검색 시 해당 파일을 사용하도록 갱신을 구성하여 Eclipse 제품에서 이러한 정책 갱신 설정 및 기타 정책 갱신 설정을 설정할 수 있습니다.

해당 파일에서는 XML 형식을 사용하고 어떤 파일 이름도 가능합니다. 파일은 갱신 정책 필드의 환경 설정>설치/갱신에서 설정할 수 있습니다. 텍스트 필드는 기본적으로 비어 있습니다. 사용자가 갱신 정책 파일의 URL을 설정할 수 있습니다. 파일은 로컬 관리자가 관리하고 모든 제품 설치 시 공유됩니다. 두 가지 방법을 통해 공유할 수 있습니다.

정책 파일은 다음 DTD를 준수해야 합니다.

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

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

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

url-map

이 요소는 기능 Manifest에 내장된 갱신 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를 제외하고 URL1에서 모든 Eclipse 기능이 갱신됩니다.

갱신 정책 파일은 변환 가능한 문자열을 포함하지 않으므로 특수 NL 처리가 필요하지 않습니다. 일반적으로 파일에서는 UTF-8 인코딩을 사용해야 합니다.

2.3 자동 갱신 발견

자동 갱신을 사용하여 Eclipse는 지정된 스케줄(매번 시작 시(기본값), 하루에 한 번, 일주일에 한 번 등)에 따라 갱신 검색을 실행할 수 있습니다.

3. 요약

다음은 솔루션을 구성하는 전체 단계 순서입니다.

  1. 관리자가 로컬 제품 갱신을 호스트하는 회사 LAN에 서버를 할당합니다. 처음에 갱신 사이트는 포함되지 않습니다. 시스템에서 HTTP 서버가 실행되고 있어야 합니다.
  2. 관리자가 해당 서버에 갱신 정책 파일을 설정하고 모든 사용자에게 갱신 정책 환경 설정을 제공된 URL로 설정하도록 지시합니다.
  3. 제품 제공자가 해당 갱신 사이트에서 갱신 및 수정사항을 제공하므로 관리자는 지원되는 갱신을 로컬 서버에 다운로드합니다.
  4. 클라이언트의 제품을 가동할 때 예정된 빈도로 실행되는 자동 갱신을 통해 로컬 갱신을 선택하여 사용자에게 알립니다.
  5. 사용자가 발견된 갱신의 설치를 선택합니다.