eclipse

ATF 설치시 주의사항 - 01

gonGon 2010. 10. 1. 16:02
# ATF 설치 순서

1. Xulrunner, Xpcom이 먼저 설치된다.
   통합된 Mozilla Xpcom update site는 문제가 있으므로  Zend에서 1.9.1을 받아서 먼저 설치하고,
   ATF update site에서는 ATF만 받는다.

2. hard binding
   Xulrunner와 Xpcom 1.9.2를 만들어 먼저 설치한 후, ATF를 설치하면 아래와 같이 에러가 난다.

Cannot complete the install because one or more required items could not be found.
  Software being installed: AJAX Tools Framework Webtools Integration (Incubation) 0.3.0.v201006041600-15-7zCN3GbYINYP5NiDOfPM (org.eclipse.atf.feature.feature.group 0.3.0.v201006041600-15-7zCN3GbYINYP5NiDOfPM)
  Missing requirement: Mozilla Browser Xulrunner embedder 0.3.0.v200909041100 (org.eclipse.atf.mozilla.swt.browser 0.3.0.v200909041100) requires 'bundle org.mozilla.xulrunner 1.9.1' but it could not be found
  Cannot satisfy dependency:
    From: AJAX Tools Framework Webtools Integration (Incubation) 0.3.0.v201006041600-15-7zCN3GbYINYP5NiDOfPM (org.eclipse.atf.feature.feature.group 0.3.0.v201006041600-15-7zCN3GbYINYP5NiDOfPM)
    To: org.eclipse.atf.mozilla.ide.feature.feature.group [0.3.0.v201006041600-17K-DZRDIVE2KhCNeOL]
  Cannot satisfy dependency:
    From: AJAX Tools Framework Mozilla IDE (Incubation) 0.3.0.v201006041600-17K-DZRDIVE2KhCNeOL (org.eclipse.atf.mozilla.ide.feature.feature.group 0.3.0.v201006041600-17K-DZRDIVE2KhCNeOL)
    To: org.eclipse.atf.mozilla.swt.browser [0.3.0.v200909041100]

org.eclipse.atf.mozilla.swt.browser 플러그인이 Xulrunner를 찾는데, 버전이 명시되어 있기 때문에 문제가 발생한다.
org.eclipse.atf.mozilla.swt.browser 플러그인은 다른 ATF 플러그인들과 달리 (MANIFEST.MF) dependancy에 Xulrunner의 번들 버전을 명시하고 있다.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: %Bundle-Name
Bundle-SymbolicName: org.eclipse.atf.mozilla.swt.browser; singleton:=true
Bundle-Version: 0.3.0.qualifier
Bundle-Vendor: %Bundle-Vendor
Bundle-Localization: plugin
Require-Bundle: org.eclipse.core.runtime,
 org.mozilla.xpcom,
 org.mozilla.xulrunner;bundle-version="1.9.1"
Fragment-Host: org.eclipse.swt;bundle-version="[3.5.0,4.0.0)"
Bundle-RequiredExecutionEnvironment: J2SE-1.4
Eclipse-LazyStart: true

그러므로 1.9.1을 먼저 설치하고 ATF를 설치한 후, 1.9.2를 update한다.
설치순서 : zend(1.9.1) -> ATF(0.3.0) -> zend(1.9.2)


cf) Mozilla에서 Xulrunner,Xpcom은 1.9.2.10까지 나와 있는데, eclipse용으로 배포하지는 않으므로 eclipse 플러그인으로 제작한 후, feature를 이용해 배포해야 한다.

cf) 실제 eclipse SWT에서 Mozilla를 사용하는 부분은 ATF와 밀결합되어 있는 흔적이 보인다.




# ATF와 SWT의 밀결합 요소
atf.cvs.psf를 이용하여 ATF 소스를 받아 설치되는 plugin들 중에 org.eclipse.atf.mozilla.swt.mozilla을 열어보자.
소스는 XULRunnerInitializer 달랑 한 개 있다. 문제가 되는 것은 package - org.eclipse.swt.browser 이다.
ATF에서 배포하는 플러그인이 왜 eclipse swt package를 사용하는 걸까?

*XULRunnerInitializer의 작동

XULRunnerInitializer는 static method initialize와 log 두 개로 구성된 class이다.
initialize는 static영역에 등록되어 있으며
Plugin으로 등록된 번들들을 뒤져 xulrunner를 찾은 후, System Property로 등록하는 일을 한다.
xulrunner 번들을 찾을 때, 

org.mozilla.xulrunner,
org.mozilla.xulrunner.win32.win32.x86, 
org.mozilla.xulrunner.carbon.macosx,
org.mozilla.xulrunner.gtk.linux.x86

와 같은 이름을 찾는다. 이 중, org.mozilla.xulrunner는 1.8 버젼에서 사용하는 relic이므로 사용하지 않도록 하자.
그럼, window일 경우 org.mozilla.xulrunner.win32.win32.x86, mac일 경우org.mozilla.xulrunner.carbon.macosx, 리눅스일 경우 org.mozilla.xulrunner.gtk.linux.x86 라는 이름의 폴더가 eclipse/plugin/ 밑에 존재해야 한다.

jar로 배포된 후, 위와 같은 이름의 폴더로 압축이 풀려야 한다는 것을 주의하자.

for (int i = 0; i < bundles.length && url == null; i++) {
Bundle bundle = Platform.getBundle(bundles[i]);
if (bundle != null)
url = bundle.getResource("/xulrunner");
}

위와 같이 번들을 찾는데 jar로 남아 있는 것은 찾지 못한다. 또한 폴더 밑에 xulrunner 폴더가 있어야 하는 것을 알 수 있다.
정상적으로 번들을 찾으면 

if (xulRunnerRoot != null) {
System.setProperty(XULRUNNER_PATH, xulRunnerRoot.getAbsolutePath());
}

위와 같이 System Property로 등록이 된다.



한편 SWT의 Mozilla를 보자.

new Browser(parent, SWT.MOZILLA);

와 같이 SWT에서 mozilla 브라우저 component를 생성할 때, 실제 생성을 책임지는 class는 Mozilla.java이다.

Mozilla.java의 작동을 살펴보자.

String mozillaPath = System.getProperty (XULRUNNER_PATH);
/*
* Browser clients that ship XULRunner in a plug-in must have an opportunity 
* to set the org.eclipse.swt.browser.XULRunnerPath system property to point
* at their XULRunner before the first Mozilla-based Browser is created.  To
* facilitate this, reflection is used to reference non-existent class
* org.eclipse.swt.browser.XULRunnerInitializer the first time a Mozilla-
* based Browser is created.   A client wishing to use this hook can do so
* by creating a fragment of org.eclipse.swt that implements this class and
* sets the system property in its static initializer.
*/
if (mozillaPath == null) {
try {
Class.forName ("org.eclipse.swt.browser.XULRunnerInitializer"); //$NON-NLS-1$
mozillaPath = System.getProperty (XULRUNNER_PATH);
} catch (ClassNotFoundException e) {
/* no fragment is providing this class, which is the typical case */
}
}

먼저 System Property에서 XULRUNNER_PATH를 찾는다. 주석에서 알 수 있듯이, 브라우저가 처음 초기화되기 이전에, 별도로 (자체)생성한 XULRunnerInitializer 클래스를 만들어, static영역에서 XULRUNNER_PATH를 등록할 것을 권하고 있다.

ATF의 XULRunnerInitializer가 static영역에서 이를 등록했고, SWT는 이를 가져다 쓰게 된다. 이 후, initXULRunner(), initXPCOM() 등을 호출하여 XPCom까지 불러온다.

# nsIWebBrowser
XPCom을 사용할 준비가 완료되면 아래와 같이 실제 browser 객체를 생성한다.

/* create the nsIWebBrowser instance */
nsID NS_IWEBBROWSER_CID = new nsID ("F1EAC761-87E9-11d3-AF80-00A024FFC08C"); //$NON-NLS-1$
rc = componentManager.CreateInstance (NS_IWEBBROWSER_CID, 0, nsIWebBrowser.NS_IWEBBROWSER_IID, result);
if (rc != XPCOM.NS_OK) {
browser.dispose ();
error (rc);
}
if (result[0] == 0) {
browser.dispose ();
error (XPCOM.NS_NOINTERFACE);
}
webBrowser = new nsIWebBrowser (result[0]);
result[0] = 0;

org.eclipse.swt.internal.mozilla 패키지에 있는 nsIWebBrowser는 nsISupports를 상속하고,
mozilla XPCOM API에 있는 nsIWebBrowser 명세를 구현하고 있다. 

cf) swt의 internal.mozilla  패키지는 XPCOM 관련 부분의 구현체인 것으로 보이는데, 이렇듯 Mozilla의 XPCOM명세를 eclipse SWT에서 구현하고 있다는 사실이 흥미롭다. 좀 더 연구가 필요하다. 
또한, Mozilla.java를 보면, AWT의 Browser 관련 부분에 대한 작동 원리를 이해하는데 많은 도움이 될 것이다.