본문 바로가기
Study/Jedi

업데이트 사이트는 왜 필요한가

by epro 2007. 3. 31.

이클립스의 장점 중 하나는 플러그인을 이용해 기능을 확장할 수 있다는 것이다.

플러그인을 설치하는 방법은?

원하는 플러그인을 찾은 후 홈페이지로부터 압축파일을 찾아 plugin디렉토리에 풀어주는 방법 혹은
update manater를 이용하는 방법. 이 두가지 방법이 많이 쓰일 것이다.

첫번째 방법은, 홈페이지에서 압축 파일을 다운받아 풀어줘야 하는 번거로움이 있다. 또 버젼업 되었는지 일일이 홈페이지에 찾아가 확인해 줘야 한다. 만약, 이런 플러그인이 몇 십개라면, 일일이 뒤져서 버젼업 되었는지 확인하는 일은 생각만 해도 번거롭다.

update manager를 사용하면 어떨까?
update manager는 feature라는 것에서 버젼을 관리해 준다. 때문에 버젼에 변경이 있을 경우 간단하게 플러그인을 업그레이드 할 수 있다.


Update Manager는 어떻게 plug-in을 설치 혹은 업데이트 시킬 수 있는 걸까?
Update Manager는 해당 plun-in의 Update Site에 접속해서 플러그인을 설치하거나 버전업 된 Plug-in을 자동으로 update 해주는 작업을 수행한다.


그림-1. Update Site

사용자 삽입 이미지


An Eclipse Update Site?

Update Site에는 plugins와 features 디렉토리가 존재한다.
plugins는 이름에서 알 수 있듯이 해당 업데이트 사이트에서 제공하는 플러그인들이 담겨져 있다.
features는 플러그인과 archive들을 그룹화 한다. update manager가 인식할 수 있는 형태로 plug-in을 패키징하는 것이다.

feature의 개념 :
feature는 Feature Id(Unique ID-플러그인 ID), Feature Name, Feature Version, Feature Provider로 구성되어 있으며 플러그인과 archive들을 그룹화한다. license정보, copyright정보, 기타 내용을 사용자에게 제공하고, 업데이트 정보를 찾기 위한 URL과 'discovery' URL을 정의하여 플러그인을 인스톨하거나 언인스톨 하고 기타 다른 유용한 정보를 찾아볼 수 있도록 하는 사용자 인터페이스를 제공한다.


Update Site의 응용

여기까지 진행하고 나니, 그럼 Update Site가 편하긴 한데..
개발의 편의성을 위해 어떻게 써먹어야 할지 궁금해진다...

다음과 같은 상황을 생각해 보자.

새로운 프로젝트가 의뢰되었다. Project Leader는 이클립스에 필요한 환경설정(plug-in 등)을 구성하고, 이것을 압축해서 팀원들에게 단체 메일을 보냈다.
"이 압축파일을 eclipse/plugins에 풀어놓으세요. 이번 프로젝트는 XX, OO,ㅁㅁ 이런 플러그인을 사용해 진행할 겁니다.." (이런 상황이 있을 수도 있겠죠? 저는 안 겪어봤지만 ^^;)
그리고 그 중, PL이 직접 만든 플러그인도 있을 수 있겠다.
여기까지는 좋은데....
만약 플러그인에서 버그가 발견됬다거나, 새로운 기능이 추가되었다면 어떻게 할까?
PL은 다시 플러그인들을 일일이 압축해서 다시 팀원들께 전체메일을 발송해야 할까?
그건.. 웬지 비효율적으로 보인다. 실용주의개발자가 되어보자..
이때 Update Site를 이용한다면?

프로젝트에 필요한 plug-in들을 모아 feature를 구성할수 있을 것이다. feature를 이용하면 버전관리가 가능하기 때문에, feature에 변경이 생겼을 경우, 필요한 부분만 다시 업데이트를 받으면 끝이다.

이 방법이 압축을 푸는 것보단 훨씬 간단해 보이지 않는가?

예로 든 team project가 아니라 더 넓게 생각해 보자,
소프트웨어 어플리케이션은 새로운 기능을 추가하고 혹은 버그를 수정하기 위해 꾸준히 업데이트 되고 있다. 이런 소프트웨어를 유저들에게 배포하는 방법은 아주 중요할 것이다. 특히 유저 베이스가 크고 분산되어 있다면 더욱 그럴 것이다.

글로벌시대에, 소프트웨어 업데이트를 위해 기술자를 파견한다는 것 생각 할 수도 없고, 메일을 보내 업데이트 하라는 것도 비효율적으로 보인다. 다행스럽게도, Eclipse 플랫폼으로 만들어진 소프트웨어는, update site를 이용해 최신 버젼을 유지하게 할 수 있다.


그럼, Update Site는 어떻게 만들 수 있을까?

이클립스에서 제공하는 플러그인 개발 환경(Plug-in Development Environment, PDE)은 update site를 간단하게 만들 수 있도록 도와준다.
( File > New > Project > Plug-in Development > Update Site Project )

사용자 삽입 이미지

만든 update site를 원격으로 제공해 유저들이 Update manager를 통해 플러그인을 설치할 수 있게 하려면 HTTP Server가 필요하다. PDE를 통해 만든 update site를 HTTP Server에 올리기만 하면 된다.


샘플 업데이트 사이트

◎ 업데이트 사이트 사용 예
feature에 아래와 같은 플러그인을 묶어서 샘플 update site를 만들어 보았다.
- junit4
- subversion
- Maven
- magical_mirror ( 필자가 만든 플러그인으로,  message를 뿌려준다. 백설공주의 "마술거울"이 타겟)

update site URL : http://www.agilejava.net/files/plugin/AJN_Sample/

◎ 설치방법
Help > Softward Updates > Find and Install.. > Search for new features to install > New Remote Site > 아래 그림처럼 name, url입력

사용자 삽입 이미지

사용자 삽입 이미지

사용자 삽입 이미지

이렇게 설치하고 이클립스를 재실행하면, 아래그림과 같이 플러그인이 설치된 걸 볼 수 있다.

사용자 삽입 이미지

툴바의 아이콘을 클릭하면 아래와 같은 메세지가 나온다.
( 세상에서 가장 아름다운 이프로... ^^;; 이해해 주시길.... ㅋㅋ)
사용자 삽입 이미지


여기까지, 간단하게 이클립스 업데이트 사이트가 왜 필요하고 프로젝트에서 어떻게 응용해보면 좋을지 생각해 보았다.
필자가 경험이 부족하여 이 방법이 썩 효율적이지 않을 수도 있고, 설명이 부족한 부분도 많은 것 같다.
부족한 분은 추후에 Jedi 스터디등을 통해 업데이트 사이트 경험을 쌓은 후 채워가면 좋을 것 같다...


# Reference
http://www-128.ibm.com/developerworks/lotus/library/sametime-updates/
(http://www.ibm.com/developerworks/kr/library/sametime-updates/)
http://www.eclipse.org/articles/Article-Update/keeping-up-to-date.html
(http://cafe.naver.com/eclipseplugin.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=76)
http://wiki.eclipse.org/index.php/Update_Site_Optimization
http://www.dbguide.net/
http://www.ibm.com/developerworks/kr/library/os-ecplug/#resources
이클립스 플러그인 업데이트 매카니즘 1장. 2장. 3장. 4장.



-----------------------------------------------------------------------------------------
추가된 이야기..

오늘(4/1) AJN에서 포스팅한 내용을 바탕으로 업데이트 사이트 시연 발표를 했었다. 발표를 준비하면서는 업데이트 사이트에 대한 지식을 쌓는 것에만 중점을 두었는데, 발표를 하면서 다른분들에 의견을 들을 수 있어 좋았다.

그 중, "프로젝트 향상을 위해 여러개의 플러그인을 피처로 묶어 업데이트 사이트에 올리면 좋겠다"고 생각했던 부분에 대해 단점을 발견해서 적어보고자 한다.

문제1. 내 이클립스에 설치된 플러그인을 피처로 묶어 업데이트 사이트에 올린다.
=> 이렇게 하면 플러그인은 새로 한 벌이 생기게 되는 것이다.
즉, 플러그인을 최초 배포했던 업데이트 사이트에 한 벌, 그리고 내가 만든 업데이트 사이트에 또 한 벌.
 이 경우, 새로운 버젼의 플러그인이 나오면, 해당 플러그인을 다시 다운받아 피쳐에서 새로 묶어 줘야 한다. 버전관리의 어려움이 예상된다. 그리고 여러개의 플러그인을 묶어놨을 경우, 하나의 플러그인만 업데이트하면 될것을 여러개를 다시 다운받아야 하므로 번거로울 수 있다.

문제2. 사이즈가 큰 플러그인을 올렸을 경우...
=> 팀원들에게 업데이트 사이트 url을 배포하고 설치하라고 했을 때, 만약 다운로드 받아야 할 플러그인 사이즈가 크다면? 시간이 엄청 오래걸리겠지...작은 용량의 여러개의 플러그인을 다운받는 것은 간단할지 몰라도, 사이즈가 큰 플러그인을 올리는 것은 비효율적일 수 있다.

댓글