 | |
|
난이도 : 중급 Genady Beryozkin, Software Developer, OCSolutions
2007 년 10 월 23 일 Eclipse는 Microsoft® Visual Studio® 개발자들에게는 새로운 것이고, Eclipse에서 시작하는 것은 혼란을 줄 수 있습니다. 플러그인 아키텍처, 워크스페이스 중심 프로젝트 구조, 자동 빌드 같은 새로운 개념들은 처음 보기에 낯설기만 합니다. 이 두 가지 환경의 차이점들을 익혀, Eclipse에 익숙해지도록 합시다.
모든 통합 개발 환경(IDE)들은 같은 목적을 위해 구현되었기 때문에 유사성을 지니고 있다. 하지만, 차이점도 있다. 이들 일부는 애플리케이션 영역에 해당하는 것이지만, 어떤 것은 IDE 디자인에서 기인한 것이기도 하다.
분명한 것은, Microsoft Visual Studio와 Eclipse는 다르다는 것이다. 자바™ 프로그래밍 언어는 C/C++/.NET과는 다르고, 자바는 Eclipse에서 지원되는 최초의 언어였다. Eclipse는 "everything and nothing in particular"용 IDE가 되는 것으로 목표로, 보다 일반적이고 커스터마이징 가능한 기능들을 도입하고 있다. Eclipse는 더 많은 OS에서 사용할 수 있다. 하지만, 필자가 이 글에서 의도하는 것은 Eclipse와 Visual Studio간 모든 차이점들을 열거하는 것은 아니다.
IDE 디자인에 대해 너무 관념적으로 흐르지 않고, IDE들간 주요 차이점들을 설명하도록 하겠다. 잠깐이라도 Visual Studio를 사용한 경험이 있고, Eclipse를 시작하려는 누구나 독자가 될 수 있다. Eclipse에서의 자바 프로그래밍은 가르치지 않으며, 자바 중심의 기능들(좋은 튜토리얼을 참고자료 섹션에 소개해 놓았다.)에도 초점을 맞추지 않겠다. 일반적인 차이점을 논할 것이다.
Eclipse 워크스페이스
|
워크스페이스 디렉토리
Eclipse 워크스페이스는 특별한 .metadata 하위 디렉토리를 포함하고 있는 파일 시스템의 디렉토리이다. .metadata 디렉토리에는 settings, cache 같은 모든 워크스페이스의 개별 정보를 포함하고 있다. 일반적으로, .metadata 디렉토리에 있는 어떤 파일도 수정해서는 안된다. 워크스페이스 디렉토리는 Eclipse의 새로운 프로젝트에 대한 기본 위치가 되기도 한다.
|
|
일반적으로, Eclipse 워크스페이스는 Visual Studio 솔루션과 같은 목적을 갖고 있다. 계층적 구조에 상위 프로젝트, 폴더, 파일을 구성한다. 하지만, 몇 가지 큰 차이가 있다. Visual Studio 솔루션은 상호 의존성, 설정, 버전 관리 정보를 사용하여 프로젝트를 단순히 리스팅 한다.
Eclipse 워크스페이스는 이보다 훨씬 더 많은 일을 한다. 글로벌 프레퍼런스, 윈도우 레이아웃, 검색, 검색 내역 같은 비-프로젝트 정보를 관리한다. Eclipse는 워크스페이스 없이 시작할 수 없고, Visual Studio 솔루션을 닫는 것과 똑 같은 방식으로 워크스페이스를 닫을 수 없다. Eclipse에서 워크스페이스들을 전환할 수 있지만, 많은 사용자들은 모든 프로젝트들을 포함하고 있는 하나의 워크스페이스를 사용한다.
프로젝트 구조
|
Eclipse 프로젝트 구조의 기원
프로젝트의 구조와 파일 시스템 레이아웃 간 엄밀한 상응성(correspondence) 자바 패키지와 파일 시스템의 레이아웃 간 의무적인 상응성에 영향을 받은 것이다. 자바 언어에서, p1.p2.p3.Class1 클래스는 p1/p2/p3 디렉토리에 있어야 한다.
Visual Studio 언어들( C/C++/C#, J#)은 이와 같은 디렉토리 구조를 의무화 하지 않는다. 결국, 프로젝트 구조와 파일 시스템 레이아웃 간 상응성은 Visual Studio에서는 그렇게 엄격하지 않다.
|
|
Eclipse 프로젝트는 기반 파일 시스템과 인터랙팅 하는 방식에 있어서 Visual Studio 프로젝트와 다르다. Visual Studio에서, 프로젝트는 파일 시스템의 레이아웃에 엄밀히 연결되지 않는다. c:\temp\ 에서 d:\work에 있는 프로젝트로 파일을 추가할 수 있고, Visual Studio는 새로운 파일에 대한 레퍼런스를 기록하고, 다른 파일처럼 이것을 열 수 있다. 폴더(예를 들어, "header files")는 파일 시스템 폴더(내부적으로, 이와 같은 폴더를 필터(filter)라고 한다.)에 상응하지 않는다.
Eclipse에서, 프로젝트의 엘리먼트 구조는 기반 파일 시스템의 레이아웃에 상응해야 한다. 예를 들어, Eclipse 프로젝트 HelloWorld(그림 1)는 c:\eclipse\workspace\HelloWorld에 있어야 하고, README.TXT는 c:\eclipse\workspace\HelloWorld\src\README.TXT에 있어야 한다.
그림 1. 간단한 HelloWorld 프로젝트
Eclipse 역시 프로젝트 디렉토리 밑의 파일들과 연동되어야 한다. Eclipse의 파일이나 폴더를 삭제하면, 파일 시스템에서 사라진다. 하지만, Windows® Explorer를 사용하여 같은 파일을 추가 또는 삭제하면, Eclipse의 관련 리소스는 연결이 해지되는데, 이는 연산 동안 Eclipse 오류를 만들어 낸다. 이와 같은 경우, 프로젝트의 오른쪽 클릭 메뉴에서 Refresh를 선택하여 프로젝트를 직접 리프레시 한다. Eclipse 프레퍼런스에서 Refresh automatically 옵션을 선택하여 파일 시스템과 자동으로 동기화 되도록 Eclipse에 명령할 수 있다.
리소스를 Eclipse에 연결하기
엄격한 워크스페이스 구조는 시작에 불과하다. 프로젝트가 워크스페이스 디렉토리 밖에 저장될 수 있지만, 초기 Eclipse 버전은 외부 파일 조차 열 수 없었다. (요즘은 File > Open File을 선택한다.) 유닉스® 사용자들은 심볼릭 링크를 사용하여 유연한 프로젝트 구조를 에뮬레이트 할 수 있지만, Windows 사용자들은 이 같은 권한이 없다. 요즘, Eclipse는 IDE 레벨에서 링크 리소스(linked
resources)를 지원한다.
Eclipse의 링크 리소스는 유닉스의 심볼릭 링크와 흡사하게 작동한다. 예를 들어, 대형 테스트 인풋 파일을 원래 위치로부터 복사하지 않고 프로젝트에 추가하려면, File > New > File을 선택하고, 열린 창에서 Advanced (그림 2)를 클릭한다. 이들이 추가된 후에, 링크 리소스들은 아이콘 위에 작은 화살표들로 꾸며진다. (그림 3)
그림 2. 링크 파일 추가하기
그림 3. HelloWorld 프로젝트의 링크 파일
팁: 링크 리소스를 사용하여 성능 향상하기
|
링크 폴더를 자바 아웃풋 폴더로서 사용하기
기존 프로젝트에 링크 폴더를 자바 아웃풋 폴더로서 사용하려면, 프로젝트가 소스와 .class 파일에 개별 폴더를 사용하고 있는지 확인해야 한다. (그렇지 않다면, 소스 파일을 개별 폴더로 이동해야 한다.) 그리고 나서, Navigator 뷰를 열어서, 자동 구현을 끄고, 오래된 아웃풋 폴더를 삭제하고, 같은 이름을 가진 새로운 링크 폴더를 만들고, 자동 빌드를 다시 켜고, Project > Clean으로 프로젝트를 재구현 한다.
|
|
링크 폴더는 파일 서버나 ClearCase 동적 뷰 같은 원격 장소에 있는 대형 프로젝트를 다룰 때 유용하다. 소스 파일이 적절하게 백업되고 관리되지만, 생성된 .class 파일을 원격 스토리지에 저장해야 하는 몇 가지 이유가 있다. 백 개 이상의 소스 파일을 가진 프로젝트에서, 생성된 파일들을 로컬 머신에 저장한다면 연산의 성능을 크게 높일 수 있다.
Visual Studio C++ 프로젝트에서, 로컬 디렉토리에 대한 중간 디렉토리를 설정함으로써 빌드 성능을 높일 수 있다. Eclipse에서는 로컬 머신의 디렉토리를 가리키는 링크 아웃풋 폴더를 사용함으로써 같은 효과를 누릴 수 있다.
참고자료 섹션에는, 유닉스의 /tmp와 Windows의 c:\temp에 임시 디렉토리를 사용하는 것처럼, 변수를 사용하여 플랫폼 기반 링크 대상들을 사용하는 방법이 소개되어 있다.
실행 세트로 클러터 줄이기
많은 개발자들은 모든 프로젝트들을 하나의 Eclipse 워크스페이스에 로딩한다. 이것은 편리하지만, 가끔 너무 많은 클러터를 만들어 낼 수 있다. 불필요한 프로젝트를 닫는 것 외에도, 엘리먼트(프로젝트, 폴더, 클래스)의 그룹인 실행 세트(working sets)를 정의할 수 있다. Eclipse는 다른 뷰(Package Explorer)와 연산(검색)에 실행 세트를 사용할 수 있다. (참고자료)
로컬 히스토리
Eclipse에서 가장 매력적인 기능이자 Visual Studio에는 없는 기능은 로컬 히스토리이다. 파일, 클래스, 메소드를 수정할 때마다, Eclipse는 로컬 히스토리에 변경 사항을 기록한다. 그리고 나서, 파일을 몇 분전, 몇 시간 전, 며칠 전의 것과 비교한다. 파일이 삭제되면, 부모의 콘텍스트 메뉴에서 Restore from Local
History를 호출하면 된다.
로컬 히스토리는 버전 관리를 대체하는 것이 아니다. 히스토리 날수와 할당된 스토리지 용량을 설정할 수 있는 수퍼-실행 취소 엔진이라고 할 수 있다.
프로젝트 구현하기
하나의 프로젝트가 하나의 프로젝트 유형(C++/C#/J#)을 갖고 있는 Visual Studio 방식과는 달리, Eclipse 프로젝트는 0 또는 1 또는 여러 자연수(nature)들을 가질 수 있다. 예를 들어, Eclipse의 자바 프로젝트는 자바 자연수를 갖고, Dynamic Web 프로젝트(Eclipse WTP를 사용하여 생성됨; 참고자료)는 자바와 (상징적) 웹 자연수를 갖는다. 프로젝트 자연수는 프로젝트가 구현될 때 실행되는 빌더 리스트를 정의한다. 예를 들어, 자바 자연수는 자바 소스 파일들을 .class 파일로 컴파일 하는 빌더를 추가하고, 웹 자연수는 XML과 HTML 파일들의 유효성 검사를 하는 빌더를 추가한다.
프로젝트를 자동으로 구현하기
|
비-자바 프로젝트 구현하기
자동 구현은 자바 프로젝트에는 완벽하다. 내부 점증적 컴파일러(Eclipse는 javac을 사용하지 않는다.)는 작은 코드 변경을 빠르게 핸들할 수 있기 때문이다. 빌드가 백그라운드에서 실행되더라도, 작은 업데이트가 길이 컴파일을 실행하는 프로젝트 유형(CDT
projects)의 경우, 자동 빌드를 끄는 것이 낫다. (Project > Build Automatically). 그 후에, 빌드를 직접 실행하거나(Project > Build All), Eclipse가 애플리케이션을 실행하기 전에 구현하도록 할 수 있다.
|
|
Eclipse를 처음 접하면, 많은 사람들은 Build 명령어를 찾는다. 하지만, 놀랍게도 찾을 수 없거나 실행 불가이다. Visual Studio와 다른 IDE와는 달리, Eclipse는 자동 빌드(automatic
build) 기능을 갖고 있다. 자바 프로젝트에서, 자바 파일이 수정될 때마다, Eclipse는 관련 파일들을 컴파일 하고, 변경 사항에 간접적으로 영향을 받는 파일도 여기에 포함된다. 자동 빌드는 다른 파일에 영향을 주는 컴파일 에러를 빠르게 복구할 수 있는 좋은 방법이다. 자바 검색 같은 많은 연산들이 이러한 빌드 결과에 의존한다.
빌드 커스터마이징
주로 C++ 프로젝트의 경우, Visual Studio 프로젝트는 커스텀 빌드 단계를 사용하여 비 표준 빌드 태스크를 수행한다. 커스텀 빌드 명령어는 Visual Studio 프로젝트의 평범한 명령어이다. 반면, Eclipse는 독립적인 프로그램과 Ant 빌드 스크립트를 실행할 수 있다. 예를 들어, Ant 스크립트를 사용하여 프로젝트가 재구현 될 때마다 프로젝트의 클래스들을 포함하는 Java Archive (JAR) 파일을 구현 및 전개할 수 있다. Ant의 build.xml 파일용 에디터가 포함되어 있다.
프로젝트의 프로퍼티 윈도우에서 Builders 페이지에 커스텀 프로젝트 빌더를 설정할 수 있고, Run > External Tools를 선택함으로써 글로벌 스크립트를 정의 및 실행할 수 있다.
실행 및 디버그
|
언어와 엔트리 포인트
Visual Studio 언어들(C++/C#)은 실행 파일 당 단 하나의 엔트리 포인트를 가질 수 있는데, 이는 링크 시 결정된다. 자바 프로그래밍 언어는 컴파일 시 다중 엔트리 포인트(main 메소드)를 허용한다. 이 엔트리 포인트는 프로그램이 시작될 때 명령행에서 결정된다.
|
|
Eclipse는 Visual Studio와 같이 시작 프로젝트의 개념을 갖고 있지 않다. 이러한 차이는 언어적 차이 때문이지만, Visual Studio는 프로젝트 당 하나의 실행 파일을 생성하고, 다른 프로젝트 설정들 전용의 명령행 인자 같은 다양한 시작 매개변수들을 허용함으로써 사용자들을 제한한다. 다른 명령행 인자를 갖기 위해 다중 설정들을 관리하는 것은 대부분의 상황에서 좋은 생각은 아니다.
Eclipse는 시작 설정(launch configurations)을 사용하여 애플리케이션을 시작할 때 사용되는 매개변수들을 모은다. 자바 프로그램의 경우, 메인 클래스 이름과 명령어 인자들이 이와 같은 매개변수들이다. 프로젝트에 main() 메소드를 사용하여 클래스용 개별 시작 설정들을 가질 수 있다. 새로운 설정은 Run > Run
As 명령어를 사용하여 새로운 메인 클래스로 애플리케이션을 시작할 때 자동으로 생성된다. 또한, Run window (Run > Run)를 사용하여 시작 설정을 생성 및 삭제할 수 있다.
기본적으로, 시작 설정은 워크스페이스에 해당하며, 프로젝트의 일부가 아니다. 다른 팀 멤버들과 공유될 수 없다는 의미이다. 프로젝트에 시작 설정을 저장하려면 Run 윈도우의 Common 탭을 사용한다.
그림 4. 시작 설정의 위치 변경하기
Debug 퍼스펙티브
Eclipse는 디버그 모드가 없다. 단, 전환이 가능한 Debug 퍼스펙티브가 있다. 메인 Debug 뷰는 실행 또는 디버그 될 수 있은 모든 프로그램들을 리스팅 하고, 동시에 여러 prograDebuggingms를 디버그 하는데, 이것을 Visual Studio에서 수행하기는 어렵다. "Eclipse 플랫폼에서 디버깅하기"(참고자료)에 Eclipse의 디버깅 기능이 자세히 나와있다.
Eclipse 플러그인
무료의 오픈 소스 자바 IDE라는 것 외에도, Eclipse의 가장 중요한 특징이자 성공 요인은 개방된 확장 아키텍처이다. 대부분의 Eclipse 기능들은 확장되거나, 플러그인에서 기여를 받는다. 사실, 많은 Eclipse 기능들은 일반 대중도 사용할 수 있는 같은 확장성 아키텍처를 사용한다.
Eclipse의 비즈니스 친화적인 오픈 소스 라이센스는 상용 및 오픈 소스 플러그인 개발을 장려한다. 800개 이상의 플러그인들이 Eclipse Plugin Central의 공식 플러그인 시장에 등록되어 있다.
기존 Eclipse에 통합되는 플러그인 외에도, 일부 기업들은 완벽한 기능을 갖춘 IDE를 Eclipse에 구현한다. 모든 IBM®
Rational® 툴, CodeGear JBuilder 2007, Genuitec MyEclipse 등이 여기에 해당한다. 일반적으로, 이러한 제품들은 모델링, 웹 개발, 시각 디자인 툴을 제공한다. (참고자료)
기타 Eclipse 프로젝트
기본적인 Eclipse software development kit (SDK)에는 자바 IDE만 포함되어 있다. 다른 언어들(C/C++, PHP)용 툴킷, 모델링 툴, 기타 확장들은 Eclipse 하에 개발되고 있고 Eclipse 플러그인으로서 설치될 수 있다. 2007년 탑 21 Eclipse 프로젝트의 최신 동시 릴리스인 Europa와, 2006년 6월의 탑 10 프로젝트의 이전 릴리스인 Callisto에 대한 자세한 내용은 참고자료를 참조하라.
Update Manager
Eclipse를 처음 다운로드 하거나 업그레이드 할 때마다, 압축 파일을 빈 디렉토리에 추출한다. 설정을 수행하거나 데스크탑 숏컷을 생성하는 어떤 인스톨러도 없다. 하지만, 플러그인의 경우, Eclipse는 Update Manager (Help > Software Updates)가 있고, 이것이 설치와 업데이트를 관리한다. 또한, Visual Studio의 Add-in Manager처럼, 플러그인을 실행/실행 불가로 한다.
Update Manager는 업데이트 사이트 (로컬 또는 웹)에서 플러그인을 설치 또는 업데이트 한다. 새로운 플러그인을 설치하려면, 벤더의 웹 사이트에서 업데이트 사이트 URL을 찾거나 Update Manager 윈도우에 이를 직접 입력해야 한다. (일부 벤더들은 업데이트 매니저와 뒤에서 상호 작동하는 완전한 인스톨러를 구현했다.)
Eclipse는 알맞은 디렉토리에 직접 복사함으로써 플러그인의 설치를 지원한다. 이 방법은 권장되지 않으며, Eclipse 설정의 일관성을 해칠 수 있다. 자세한 내용은 "기본적인 문제 해결"을 참조하라.
도움이 필요할 때
Eclipse 초보자라면, 의문 사항도 있을 것이다. 얼마간 사용한 후에, 몇 가지 버그를 발견할 수 있고, 새로운 기능을 제안하고 싶을 수도 있다. 본 섹션에서는 다양한 지원 옵션들을 소개한다.
기본적인 문제 해결
모든 사람들은 가끔은 IDE도 오작동 할 수 있다는 것을 알고 있다. Visual Studio에서, 명령어 프롬프트에서 devenv
/setup을 입력하여 팩토리 상태로 리셋할 수 있다. Eclipse도 비슷한 명령행 스위치를 제공한다. 명령행에서 eclipse.exe -clean을 실행하면, 설치된 플러그인에 대한 대부분의 정보가 재구현된다. -clean 옵션은 새로운 플러그인을 설치할 경우 유용하다.
Eclipse가 오작동 할 때, 에러 로그를 체크해야 한다. Error Log 뷰를 열려면, Window > Show View > Error Log를 선택한다. 미가공 로그가 <workspace dir>/.metadata/.log 파일에 있다.
뉴스 그룹
Microsoft 제품으로 작업했다면, Microsoft Developer Network (MSDN) 포럼과 뉴스 그룹에서 도움을 얻을 수 있다는 것을 알 것이다. Eclipse 커뮤니티도 고유의 뉴스 그룹이 있으며(참고자료), 많은 Eclipse 사용자들이 이곳에서 도움을 받고 있다.
버그 리포팅 및 새로운 기능 요청
고객 지원을 제공하는 것이 목표인 Microsoft Connect 웹 사이트의 Microsoft 피드백 기능과는 달리, Eclipse Bugs는 Eclipse 개발자들이 사용하는 실제 버그 트래킹 시스템이다. Eclipse Bugs에서, 버그 검색, 리포트, 투표는 물론, 다른 사람의 버그에 대해 CC로서 스스로를 추가할 수 있다. 버그 픽스에 누가 할당되었는지를 파악하고, 픽스되어야 할 버전을 파악한다. 같은 인터페이스를 사용하여 기능 요청도 할 수 있다. (참고자료).
프리미엄 지원
Eclipse Bugs의 오픈 소스 정신과 커뮤니티 지원 외에도, 일부 기업들은 상용 수준의 지원을 필요로 하고 있다. Eclipse에 구현된 제품을 구매하면, 벤더는 제품을 지원하고 기반 Eclipse 컴포넌트도 지원한다. 기본 Eclipse SDK를 사용하면, 월드와이드 24x7x365 지원 플랜에 따라 Eclipse 프로그램의 IBM Rational Elite Support를 받을 수 있다.
결론
Eclipse의 IDE와 태스크에 대해 설명했다. 워크스페이스 중심의 방식과 프로젝트 구조, 또 다른 한편의 UI 디자인과 시작 설정이라는 유연성이 Eclipse를 독보적으로 만든다. 확장적 아키텍처는 Eclipse를 서드 파티 플러그인과 제품을 위한 플랫폼으로 만든다.
아직 이해가 안되었다면, "Visual Studio 개발자를 위한 Eclipse" 튜토리얼(참고자료)을 읽어 보기 바란다. 그러나, Eclipse는 자바 프로그래밍 언어에 대한 것만은 아니다. C++ IDE. 같은 추가 Eclipse 프로젝트를 위한 Callisto와 Europa 릴리스도 검토하기 바란다. Eclipse Plugin Central에 방문하여 Eclipse 플러그인을 다운로드 하라.
참고자료 교육
제품 및 기술 얻기
토론
필자소개 | 
| | Genady Beryozkin은 9년 이상의 경력을 갖춘 소프트웨어 개발자이다. 다양한 C++와 C# 프로젝트에 Visual Studio를 사용했으며, 2001년 최초의 1.0 버전부터 자바 개발에 Eclipse를 사용했다. 2002년에, Java Remote Method Invocation (RMI)를 사용하는 애플리케이션을 효과적으로 개발, 디버그, 실행할 수 있는 Eclipse용 RMI 플러그인을 만들었다. 이스라엘 Technion에서 컴퓨터 공학 학사/석사 학위를 받았다. |
기사에 대한 평가
| |
