Vyuºití dynamického modulárního systému OSGi pro tvorbu modulárních geoinformatických aplikací. Bc. Zora Ho ej²ová

ƒeské vysoké u ení technické v Praze Fakulta stavební Katedra mapování a kartograe Diplomová práce Vyuºití dynamického modulárního systému OSGi pro tvorbu modulárních geoinformatických aplikací Bc. Zora Ho ej²ová Vedoucí práce: Ing. Jan Pytel, Ph.D. Studijní program: Geodézie a kartograe, magisterský Studijní obor: Geoinformatika 6. prosince 2011

Pod kování D kuji p edev²ím vedoucímu diplomové práce Ing. Janu Pytlovi Ph.D. za vedení a cenné p ipomínky. Up ímné díky pat í hlavn mé rodin za podporu b hem celého studia nejen na vysoké ²kole a také Ing. Martinu Fouskovi a jeho rodin za projevenou p íze a podporu. v

vi

Prohlá²ení Prohla²uji, ºe jsem p edloºenou práci vypracoval/a samostatn a ºe jsem uvedl/a ve²keré pouºité informa ní zdroje v souladu s Metodickým pokynem o etické p íprav vysoko²kolských záv re ných prací. V P íbrami dne 6. prosince 2011............................................................. vii

viii

Abstract This thesis is devoted to an analysis of OSGi technology and its use in geoinformatics applications. OSGi is a dynamic modular system for the Java programming language and is widely usable in all types of applications in which the ability to add new functionality and easy updates is required. Besides OSGi, the work also focuses on RCP systems, such as Eclipse RCP and NetBeans RCP, and especially their use in the development of modular applications hosting OSGi modules. Three simple sample applications with a geoinformatics focus, comprised of the mentioned bundles, will serve as an illustrative example of the use of the specied technology. Key words OSGi Service Platform, OSGi bundle, OSGi in geoinformatics, Rich Client Platform, Eclipse RCP, NetBeans RCP, Equinox, Netigso, Netbinox Abstrakt Tato práce se v nuje analýze OSGi technologie a jejímu vyuºití v geoinformatických aplikacích. OSGi je dynamický modulární systém pro programovací jazyk Java, ²iroce vyuºitelný ve v²ech typech aplikací, v nichº se poºaduje moºnost dopl ování nové funkcionality a snadné aktualizace. Krom OSGi se práce zam uje na RCP systémy, jako je Eclipse RCP a Net- Beans RCP, a zvlá² jejich vyuºití ve vývoji modulárních aplikací hostujících OSGi moduly. Názornou ukázkou pouºití zmín ných technologií budou t i jednoduché vzorové aplikace geoinformatického zam ení, sloºené ze zmín ných bundl. Klí ová slova OSGi Service Platform, OSGi bundle, OSGi v geoinformatice, Rich Client Platform, Eclipse RCP, NetBeans RCP, Equinox, Netigso, Netbinox ix

x

Obsah I Úvod 1 1 Úvod 3 2 Popis problému, specikace cíle 5 2.1 Modulární aplikace................................. 5 2.1.1 OSGi specikace.............................. 5 2.1.2 RCP systémy................................ 6 2.2 Cíle diplomové práce................................ 6 II Analýza a návrh e²ení 9 3 OSGi Service Platform 11 3.1 OSGi Alliance.................................... 11 3.2 OSGi Framework.................................. 11 3.2.1 Security Layer............................... 12 3.2.1.1 Základ Java 2 Security architektury.............. 12 3.2.2 Module Layer................................ 14 3.2.2.1 Bundle.............................. 14 3.2.2.2 Závislosti............................. 17 3.2.2.3 Execution Environment..................... 17 3.2.2.4 Class-loading........................... 17 3.2.2.5 Lokalizace............................. 18 3.2.2.6 Fragmenty............................ 20 3.2.2.7 Extension Bundles........................ 20 3.2.3 Life Cycle Layer.............................. 20 3.2.4 Service Layer................................ 21 3.3 Minimální bundle.................................. 22 3.4 Implementace OSGi................................ 23 3.4.1 Eclipse Equinox............................... 23 3.4.2 Apache Felix................................ 23 3.4.3 Concierge.................................. 23 3.4.4 JBoss.................................... 23 3.4.5 Knopersh................................. 24 3.4.6 ProSyst................................... 24 xi

4 Modularita bez OSGi 25 4.1 Java Plug-in Framework.............................. 25 4.2 Java Simple Plugin Framework.......................... 25 4.3 jin-plugin...................................... 26 4.4 NetBeans Platform Modular Runtime Container................ 26 4.5 C-Plu........................................ 26 4.6 Qt Plugins...................................... 26 4.7 Plug......................................... 27 4.8 Pluma........................................ 27 5 Rich Client Platform 29 5.1 Eclipse RCP..................................... 29 5.1.1 Struktura zdrojových kódu........................ 30 5.1.2 Workbench................................. 31 5.1.2.1 Extension body.......................... 31 5.1.2.2 Advisors............................. 32 5.1.2.3 šivotní cyklus.......................... 33 5.1.2.4 Perspektivy............................ 34 5.1.2.5 Pohledy a editory........................ 36 5.1.2.6 Akce................................ 37 5.1.2.7 P íkazy.............................. 38 5.2 NetBeans RCP................................... 40 5.2.1 Netigso................................... 40 5.2.2 Netbinox.................................. 41 III Realizace 43 6 Bundly 45 6.1 Bundly poskytující API.............................. 45 6.1.1 core.api................................... 45 6.2 Bundly zobrazující data.............................. 46 6.2.1 display.bundles............................... 47 6.2.2 display.cuzk.map.............................. 47 6.2.3 display.points................................ 48 6.2.3.1 parser.coordinats.csv....................... 48 6.3 Bundly poskytující uºivatelské rozhraní...................... 49 6.3.1 ui.manager.bundles............................. 49 6.3.2 ui.display.canvases............................. 50 6.3.3 Eclipse RCP................................ 50 6.3.3.1 ui.eclipse.display......................... 51 6.3.3.2 ui.eclipse.dialogs......................... 53 6.3.4 NetBeans RCP............................... 54 6.3.4.1 ui.netbeans.display........................ 55 6.3.5 Swing.................................... 56 6.3.5.1 ui.swing.display......................... 57 xii

6.3.5.2 ui.swing.dialogs.......................... 57 7 Základ aplikace 59 7.1 Eclipse RCP aplikace................................ 59 7.2 NetBeans RCP aplikace.............................. 60 7.3 Aplikace bez RCP................................. 62 8 Aplikace 65 8.1 geoplug.swing.................................... 65 8.2 geoplug.eclipse................................... 66 8.3 geoplug.netbeans.................................. 67 IV Záv r 69 9 Záv r 71 Literatura 73 A Seznam pouºitých pojm a zkratek 81 B P ehled bundl a jejich t íd 83 B.1 core.api....................................... 83 B.2 display.bundles................................... 83 B.3 display.cuzk.map.................................. 83 B.4 display.points.................................... 84 B.5 ui.display.canvases................................. 84 B.6 ui.manager.bundles................................. 84 B.7 ui.eclipse.dialogs.................................. 84 B.8 ui.eclipse.display.................................. 84 B.9 ui.netbeans.display................................. 85 B.10 ui.swing.dialogs................................... 85 B.11 ui.swing.display................................... 85 B.12 geoplug.eclipse................................... 85 B.13 geoplug.netbeans.................................. 86 B.14 geoplug.swing.................................... 86 C Obsah p iloºeného CD 87 xiii

xiv

ƒást I Úvod 1

Kapitola 1 Úvod Vývoj aplikací vyuºívajících modularitu jiº není pouze na vzestupu, ale pravd podobn se práv nachází na svém vrcholu. Je tém jisté, ºe ho v blízké budoucnosti z vrcholu ºádný nový technologický postup nesesadí a modulární aplikace tu s námi budou velmi dlouho. Malé jednoú elové programy samoz ejm modularitu vyuºívat nemusí a asi ani nebudou, jejich podíl na trhu je v²ak p eci jen men²inový. Modulární aplikace je takový software, jehoº funkcionalita je rozd lena do men²ích, na sob mén i více závislých jednotek zvaných moduly nebo pluginy. Výhody jsou nasnad. Distribuce m ºe probíhat po ástech a kaºdý uºivatel má moºnost zvolit si vlastní konguraci poºadovaného software nap. PHP programátor ve svém vývojovém prost edí nepot ebuje nástroje pro psaní C++ kódu a naopak se mu hodí je²t HTML editor. Taková kongurace na míru urychluje start aplikace a také sniºuje pam ové nároky. Pokud je software placený, uºivatel tímto zp sobem m ºe zna n u²et it a zaplatit pouze za to, co skute n pot ebuje. Dal²í výhodou je snadn j²í aktualizace aplikace sta í p einstalovat ty moduly, ve kterých do²lo k n jakým zm nám. Samoz ejmostí je také snadná roz²i itelnost funkcí aplikace jak z pohledu programátora, tak z pohledu uºivatele. Kaºdý developer modulární aplikace m ºe vyuºít n který z jiº existujících modulárních systém, nebo si vytvo it sv j vlastní, zcela nový. N koho jist napadne, pro existuje tolik systém, kdyº je základ modularity velmi jasn zadaný a kaºdý modul spolu se svým runtime prost edím 1 musí vypadat tém stejn. Pokud by v²echny aplikace vyuºívaly stejný modulární systém, bylo by moºné pouºívat n které pluginy i v jiných aplikacích, neº pro které byly p vodn napsány. Také programáto i by se nemuseli u it pouºívat vºdy nový systém. Na základ této my²lenky vznikla specikace dynamického modulárního systému pro programovací jazyk Java zvaného OSGi. OSGi Alliance vytvo ila otev enou specikaci p vodn pro pouºití v za ízeních chytrých domácností nebo automobil, ºádný pouºitelný modulární 1 Runtime prost edí je v tomto významu sou ást spu²t né aplikace obstarávající správu modul. Jedná se jak o jejich spou²t ní, tak o vzájemné sdílení i skrývání t íd v modulech obsaºených. 3

KAPITOLA 1. ÚVOD systém v²ak nevyvinula. Toho se ujalo hned n kolik jiných skupin i spole ností, a tak vzniklo pár voln ²i itelných implementací této specikace, vyuºitelných kaºdým, kdo má zájem. Jedna z dne²ních nejlep²ích implementací vznikla na p d spole nosti Eclipse Foundation a stala se dokonce základem vývojového prost edí poskytovaného touto spole ností Eclipse IDE 2. Vyuºití systému OSGi je velice ²iroké a m ºe být uplatn no ve v²ech moºných typech aplikací. Geoinformatické aplikace bývají asto velmi rozsáhlé a p ímo jako d lané pro roz len ní funkcionality do modul. Takovým mamutím software je nap íklad ArcGIS 3, který p ímo vybízí k roz²i itelnosti pomocí plugin. Nemusí v²ak být e pouze o velkých zahrani ních aplikacích, ale i takový Koke² 4 umoº uje p idávání modul. Otázkou z stává, zda by se spole nosti vyvíjející tyto zpoplatn né programy vyrovnaly s faktem, ºe by se n které jejich moduly mohly nainstalovat i do konkuren ních software, kdyby pouºívali modulární systém OSGi. Pro pouºití cizího modulu by se musel hostující software upravit, aby byl schopen s modulem komunikovat, existují ale takové ásti kódu, které jsou velmi p ísn st eºeny a u nichº by úprava stávajícího software pro následující vyp j ení (nebo dokonce nelegální uºívání) modulu stála za to. Náplní této práce je provedení analýzy technologie OSGi a také vytvo ení n kolika ukázek jejího pouºití. S modulárními aplikacemi také souvisí vyuºívání RCP (Rich Client Platform), jako je Eclipse RCP, jeº p ímo vyuºívá OSGi implementaci jako své runtime prost edí pro OSGi moduly. Analýza se tudíº bude týkat rovn º této platformy a zmín ná bude i konkuren ní NetBeans RCP. Ukázky budou samoz ejm demonstrovat také vyuºití t chto platforem ve spojení s OSGi. Téma diplomové práce bylo zvoleno s p ihlédnutím k nedostatku jakýchkoliv materiál v eském jazyce na téma OSGi a také s úmyslem nazna it vyuºití této technologie v geoinformatických aplikacích, které, jak jiº bylo zmín no, jsou velmi vhodné k pouºití modularity a tedy OSGi. 2 www.eclipse.org 3 www.esri.com/software/arcgis/ 4 www.gepro.cz/geodezie-a-projektovani/kokes/ 4

Kapitola 2 Popis problému, specikace cíle Výhody vývoje modulárních aplikací budou nastín ny v první ásti této kapitoly, stejn tak jako moºnosti vyuºívání OSGi v geoinformatických aplikacích. Druhá ást kapitoly se bude zabývat seznamem vyty ených cíl této diplomové práce. 2.1 Modulární aplikace Velmi mnoho aplikací, s nimiº se po íta oví uºivatelé setkávají kaºdý den, má moºnost instalace takzvaných plugin neboli modul. Tato modularita p iná²í nespo et výhod jak pro uºivatele, tak pro poskytovatele software a programátory. S plusy p ichází i n jaký ten mínus, a to hlavn sloºit j²í návrh vznikající aplikace a programování jejích základ. Výhody ale jasn p evaºují, coº je nasnad, jelikoº kdyby tomu tak nebylo, modulární aplikace by se nepouºívaly a jejich budoucnost by byla mizivá. T mito klady jsou hlavn : jednoduché poskytování nové funkcionality koncovým uºivatel m, jednoduchá moºnost aktualizace nebo p echod na vy²²í verzi, snadné programování nových funkcí pomocí implementace daných rozhraní aplikace. 2.1.1 OSGi specikace P i vytvá ení modulárních aplikací se developer musí rozhodnout, jaký framework pouºije a v jakém runtime prost edí budou existovat moduly skládající se v kone nou aplikaci. Jinými slovy, vybírá systém obsahující runtime prost edí spolu s API pro vytvá ení nových plugin. Vºdy je moºné, aby programátor vyvinul nový modulární systém sám. Bylo by to ale sloºité 5

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE a hlavn zbyte né. Dnes jiº existuje n kolik takovýchto systému, z nichº n které jsou vyvíjeny k volnému uºívání, n které i jako open-source 1. Nevýhodou je, ºe v t²ina t chto systém není navzájem kompatibilní, a tudíº nem ºe být plugin ur ený pro jedno runtime prost edí nainstalován do jiného. Kv li tomuto problému vznikla OSGi specikace, jejíº implementací vzniká modulární systém kompatibilní se v²emi jinými implementacemi téºe specikace. Jednotlivé implementace (jako je Equinox nebo Apache Felix) musí vºdy poskytovat zmín né runtime prost edí s t ídami umoº ující správu plugin. N které modulární systémy nevyhovující této specikaci byly dokonce upraveny do podoby podporující i pluginy OSGi specikace zvané bundly 2 (nap. NetBeans systém). 2.1.2 RCP systémy I kdyº se programátor rozhodne vyuºít jiº existující modulární systém, nap íklad n kterou z OSGi implementací, musí se postarat o uºivatelské rozhraní (UI) spravující nainstalované pluginy s moºností instalace nových a dal²ích funkce. Samoz ejm i tady by ²lo o znovuobjevování kola, jelikoº mnoho takovýchto uºivatelských rozhraní jiº bylo napsáno a je velmi pravd podobné, ºe lépe, neº by byly napsané ty nové. V t²inou neobsahují pouze manaºer plugin, ale i jiné asto pouºívané prvky UI. Pokud jsou takovéto knihovny p ipraveny pro snadné pouºití a konguraci ve vývoji celistvých aplikací bohatých na UI, nazývají se rich client platform neboli RCP. P íkladem takových platforem je Eclipse RCP a NetBeans RCP. Díky nim mohou programáto i vyvíjet aplikace s komplexním uºivatelským rozhraním bez nutnosti znovu psát kód uº mnohokrát napsaný. Ob zmín né platformy jsou pluginovatelné, av²ak pouze Eclipse RCP vyuºívá OSGi implementaci a tudíº je pln kompatibilní s OSGi bundly. NetBeans platforma v²ak také umoº uje instalaci bundl, i kdyº tuto podporu neobsahuje nativn. 2.2 Cíle diplomové práce Tato diplomová práce na téma Vyuºití dynamického modulárního systému OSGi pro tvorbu modulárních geoinformatických aplikací je zam ená p eváºn teoretickým sm rem a není jejím cílem naprogramovat ucelenou geoinformatickou aplikaci. Bude se zabývat OSGi technologií a jejím propojením s Eclipse Rich Client Platform a NetBeans platformou. Pro názornost bude sou ástí práce n kolik naprogramovaných ukázek vyuºití zmín ných technologií. 1 Open-source software je poskytován k bezplatnému uºívání a zárove jsou jeho zdrojové kódy ve ejn dostupné. 2 Bundle se p ekládá jako modul, v tomto dokumentu budu uºívat po e²t ný tvar p vodního anglického slova bundle kv li zachování terminologie. 6

2.2. CÍLE DIPLOMOVÉ PRÁCE Analytická ást práce se bude zabývat OSGi specikací, a to hlavn popisem jednotlivých vrstev, na které se OSGi framework d lí. Smysl OSGi specikace v²ak p ichází aº s implementací, a p estoºe jich existuje n kolik, krom rozsahu implementace v nich není velkých rozdíl. Pro praktickou ást diplomové práce byla vybrána implementace od Eclipse Foundation Equinox. Tato implementace byla zvolena také díky jejímu propojení s Eclipse platformou, jejíº analýza je rovn º sou ástí tohoto dokumentu. Zmín ny budou také zp soby vývoje modulárních aplikací bez OSGi. Praktická ást práce bude obsahovat n kolik ukázek vyuºití OSGi v programování geoinformatických aplikací. Tyto ukázky budou zasazeny do t í základních aplikací, dv z nich budou vyuºívat zmín né platformy a t etí bude oby ejná Java aplikace pouºívající grackou knihovnu Swing. Výsledkem programátorských prací bude n kolik OSGi plugin neboli bundl. Jejich zam ením budou geoinformatická témata a ty d leºit j²í z nich jsou uvedeny v následujícím seznamu: parser.coordinates.csv bundle získávající sou adnice z CSV 3 souboru, display.points plugin vykreslující zadané body na obrazovku, display.cuzk.map tento bundle získá katastrální mapu pomocí WMS 4 poskytované ƒúzk 5 na zadaných sou adnicích a ve vybraném m ítku a vykreslí ji na obrazovku, ui.manager.bundles uºivatelské rozhraní umoº ující instalaci a správu bundl. K bundl m zmín ným vý²e bude samoz ejm dopln no n kolik dal²ích pomocných bundl, nap íklad knihovny nebo pluginy poskytující UI. 3 CSV, celým názvem Comma-Separated Values, je jednoduchý textový formát uchovávající tabulková data. Poloºky v ádcích jsou odd leny zvoleným znakem b ºn se jedná o árku nebo st edník. 4 WMS je zkratkou pro termín Web Map Service p ekládaný jako webová mapová sluºba. Jde o standardizovanou sluºbu poskytující mapy v podob rastrových dat v prost edí internetu. 5 ƒeský ú ad zem m ický a katastrální dále zmi ovaný pouze pod zkratkou ƒúzk. 7

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE 8

ƒást II Analýza a návrh e²ení 9

Kapitola 3 OSGi Service Platform 3.1 OSGi Alliance OSGi Alliance byla zaloºena v b eznu roku 1999, aby vytvo ila voln ²i itelnou specikaci pro poskytování nových sluºeb do lokálních za ízení pomocí internetu. Aliance tedy vytvo ila OSGi Service Platform (dále jen OSGi, nebo platforma) specikaci, která umoº uje developer m vyvíjet, spravovat a poskytovat sluºby jednodu²e po síti v podob takzvaných bundl. Díky p vodnímu zám ru vyuºívat OSGi v za ízeních pro chytré domácnosti, automobily nebo mobilní telefony je vlastní OSGi Framework velmi kompaktní, práv kv li omezené kapacit pro ukládání dat na v t²in t chto p ístroj. Aktuální specikace ([6]) je verzí 4.3 a je moºné ji najít na stránkách aliance [5]. 3.2 OSGi Framework OSGi Framework je jádrem celé aplikace zaloºené na OSGi platform. Má na starosti správu bundl, jako je jejich instalace, aktualizace i deaktivace. Funk nost frameworku je rozd lena do n kolika vrstev, které jsou zobrazeny na obrázku 3.1 staºeném z [5]: Security Layer Module Layer Life Cycle Layer Service Layer 11

KAPITOLA 3. OSGI SERVICE PLATFORM 3.2.1 Security Layer Obrázek 3.1: Vrstvy OSGi frameworku Security Layer je nepovinná vrstva prolínající se celou platformou. Je zaloºena na Java 2 Security architektu e a vypl uje n která její prázdná místa. Obrázky v této sekci jsou p evzaty z [4]. 3.2.1.1 Základ Java 2 Security architektury P vodní bezpe nostní model je ozna ován jako sandbox model a JVM v n m poskytuje pouze omezený prostor pro spou²t ní ned v ryhodného kódu získaného z internetu. Oproti tomu lokální kód je povaºován za absolutn d v ryhodný a má plný p ístup k systému. Tento model je znázorn n na obrázku 3.2. Obrázek 3.2: JDK 1.0 Sandbox Model S p íchodem JDK 1.1 se objevuje pojem signed applet podepsaný kód získaný z internetu, který má stejná práva jako lokální kód. Nepodepsaný kód stále b ºí v omezeném prostoru sandboxu. Tento roz²í ený model je zobrazen na obrázku 3.3. Zmín né modely se týkají bezpe nosti p i spou²t ní Java aplikací, av²ak jiný pohled na bezpe nost se naskýtá jiº p i psaní samotného kódu, ne aº p i jeho spou²t ní. Díky n kolika 12

3.2. OSGI FRAMEWORK Obrázek 3.3: JDK 1.1 Sandbox Model mechanism m je syntaxe (a n které dal²í aspekty) programovacího jazyka Java bezpe n j²í neº n kterých jiných, jako nap íklad C a C++. Jedná se p edev²ím o typovou bezpe nost, správu pam ti, garbage collector nebo kontrolu indexace polí a et zc. Dal²í verzí bezpe nostního modelu pouºívaného do dnes je Java 2 Platform Security Model, který je zobrazen na obrázku 3.4. Obrázek 3.4: Java 2 Platform Security Model Tento model spl uje následující poºadavky: jemnozrnná kontrola p ístupu, jednodu²e nastavitelná bezpe nostní politika, jednodu²e roz²i itelná struktura kontroly p ístupu, bezpe nost je kontrolována u v²ech Java aplikací, ne jen u t ch získaných z internetu. 13

KAPITOLA 3. OSGI SERVICE PLATFORM V tomto modelu je základním blokem ohrani ující skupinu jednotek se stejnými právy protection domain (doména ochrany). Lze si ji p edstavit jako skupinu t íd, jimº jsou p id lená totoºná práva (obr. 3.5). Jiº v po áte ním sandbox modelu se tento princip ochrany objevoval v podob vlastního sandboxu. Domény ochrany se d lí na dv kategorie, a to na systémovou doménu a doménu aplikace. Systémová doména obsahuje ty t ídy, které jsou umíst né na systémové classpath 1 a p vodn vlastn s ºádnou doménou spjaté nejsou. Obrázek 3.5: Protection domain 3.2.2 Module Layer Module Layer denuje obecný a standardizovaný model modularizace pro Javu s p ísnými pravidly pro sdílení a skrývání Java balí k mezi bundly. Tato vrstva m ºe být pouºita bez Service Layer i Life Cycle Layer. Jednotka modularizace se v OSGi terminologii nazývá bundle, jak jiº bylo n kolikrát e eno. 3.2.2.1 Bundle Bundle je jednotka modularizace obsahující t ídy a jiné zdroje (resources). Konkrétn jde o klasický JAR 2 soubor s jistými vlastnostmi odli²ující ho od jiných JAR archiv : obsahuje pot ebné t ídy a zdroje pro provád ní ur ité funkcionality, obsahuje manifest popisující obsah bundlu a jeho závislosti, m ºe obsahovat dokumentaci v OSGI-OPT adresá i. 1 Classpath je cesta k soubor m, které obsahují t ídy pot ebné k b hu spou²t né Java aplikace. 2 JAR je zkratkou pro Java Archive a jde o soubor zabalený ZIP kompresí s koncovkou.jar. 14

3.2. OSGI FRAMEWORK Ve²kerý obsah bundlu je pro ostatní bundly neviditelný. Výjimku z tohoto pravidla tvo í takzvané exportery a importery. Jde o bundly, které své balí ky nabízejí k pouºití ostatním exportery, nebo naopak p ijímají balí ky od jiných bundl importery. Mechanismus sdílení a skrývání balí k je umoºn n díky speciálním pravidl m pro class-loadery 3. Kaºdý bundle má sv j vlastní class-loader. To v²ak neznamená, ºe class-loader na ítá t ídy pouze ze svého bundlu. Na ítá i ty, které jsou s bundlem úzce spojené, tzn. ty, které se nacházejí v: boot classpath java.* balí ky, framework classpath balí ky frameworku, prostor bundlu oblast t íd dosaºitelná z daného bundlu: rodi ovský class-loader, importované balí ky, poºadované bundly, vlastní classpath, p ipojené fragmenty. V ºádném prostoru bundlu se nemohou nacházet dv i více t íd se stejným fully quali- ed 4 jménem. Pokud nejsou umíst né v jednom prostoru, shodným pojmenováním problém nevzniká. Bundly mezi sebou komunikují pomocí Service Layer. Vºdy, kdyº je bundle nastartován, jsou jeho sluºby (services) poskytnuty v²em ostatním bundl m instalovaným ve frameworku. Kaºdý JAR archiv reprezentující bundle musí obsahovat soubor META-INF/MANIFEST.MF s denovanými hlavi kami popisujícími bundle a jeho závislosti. Hlavi ky specikované OSGi aliancí jsou: Bundle-ActivationPolicy zp sob aktivace bundlu frameworkem, Bundle-Activator jméno t ídy starající se o spu²t ní a zastavení bundlu, Bundle-Category árkou odd lený seznam kategorií, do kterých bundle spadá, Bundle-ClassPath árkou odd lený seznam cest k JAR soubor m i sloºkám obsahujících t ídy a jiné zdroje, Bundle-ContactAddress kontaktní adresa poskytovatele bundlu, Bundle-Copyright copyright bundlu, 3 Class-loader je objekt na ítající t ídy z p íslu²ných soubor. Na ítání t íd se neprovádí p i startu aplikace, ale aº p i pot eb konkrétní t ídy. 4 Fully qualied jméno je jednozna ný identikátor libovolné entity. V Java terminologii se jedná o jméno t ídy následující po kompletním jménu balí ku, nap. java.lang.classloader 15

KAPITOLA 3. OSGI SERVICE PLATFORM Bundle-Description popis bundlu, Bundle-DocURL URL adresa k dokumentaci, Bundle-Icon seznam URL adres k ikonám r zných velikostí, Bundle-License licence bundlu, Bundle-Localization umíst ní lokaliza ních soubor, Bundle-ManifestVersion verze manifestu (ur ená verzí specikace), Bundle-Name jméno bundlu, Bundle-NativeCode seznam native code knihoven, Bundle-RequiredExecutionEnvironment (deprecated) seznam prost edí, které musí být p ítomné pro spu²t ní bundlu, Bundle-SymbolicName identika ní jméno bundlu, Bundle-UpdateLocation URL adresa, kde se nacházejí aktualizace tohoto bundlu, Bundle-Vendor popis poskytovatele bundlu, Bundle-Version verze bundlu, DynamicImport-Package seznam balí k, které se mohou importovat, pokud jsou pot eba, Export-Package seznam exportovaných balí k, Export-Service (deprecated) seznam sluºeb, které bundle vkládá do registru, Fragment-Host seznam bundl hostujících tomuto fragmentu, Import-Package seznam importovaných balí k, Import-Service (deprecated) seznam importovaných sluºeb, Provided-Capability seznam poskytovaných schopností, Require-Bundle seznam bundl, jejichº v²echny exportované balí ky musí být importovány, Require-Capability seznam poºadovaných schopností od jiných bundl. 16

3.2. OSGI FRAMEWORK 3.2.2.2 Závislosti Kaºdý bundle je závislý alespo na jednom dal²ím objektu. Tím základním je balí ek implementace frameworku a dal²ími mohou být jiné bundly, execution environment, sdílené knihovny a dal²í. Bez uspokojení t chto závislostí nem ºe být bundle spu²t n. Proces spojování jednotlivých objekt mezi sebou se nazývá resolving. Pokud jsou vy e²eny v²echny závislosti, framework vytvo í pro bundle vlastní class-loader, nebo m ºe po kat s vytvo ením aº p i p ímé pot eb bundlu. Zvlá²tní výjimkou jsou dynamické importy, coº jsou závislosti, které se e²í aº p i na ítání t íd (class-loading). M ly by se pouºívat aº jako poslední moºnost. Bundle totiº m ºe být ozna en jako resolved aniº by bylo jisté, zda bude dynamicky importovaný balí ek skute n úsp ²n na ten. Závislosti je moºné, krom jiných, vyjád it hlavi kami Require-Capability a Provide-Capability. V²echny schopnosti (capabilities) v²ech bundl, které mají vy e²ené závislosti, tvo í mnoºiny atribut v daných jmenných prostorech, na které jsou aplikovány poºadavky ltra ní výrazy získané z hlavi ek Require-Capabilty. Poºadavek je uspokojen vºdy, kdyº existuje alespo jedna schopnost odpovídající ltru. 3.2.2.3 Execution Environment Prost edí JRE poskytuje v²echny balí ky v java.* jmenném prostoru, jehoº struktura a obsah se li²í pro r zné opera ní systémy a verze. Protoºe bundly balí ky z java.* neimportují, nemohou specikovat závislost na verzi Javy p ímo pomocí Import-Package, mohou v²ak poºadovat jistou schopnost jmenného prostoru osgi.ee a tím závislost ur it. Zastaralá verze tohoto postupu je vyuºití hlavi ky Bundle-RequiredExecutionEnvironment místo Require-Capability. OSGi framework ve jmenném prostoru osgi.ee poskytuje takové schopnosti podle prost edí, na kterém b ºí, aby uspokojil poºadavky bundl, které na tomto prost edí mohou b ºet díky zp tné kompatibilit verzí Javy. 3.2.2.4 Class-loading P i na ítání t íd neboli class-loadingu se dodrºují jistá pravidla prohledávání. Pokud classloader dostane od bundlu poºadavek, ídí se následujícím algoritmem, který je také vyjád en na obrázku 3.6 zkopírovaném z [6]: 1. Pokud zdroj za íná na java., poºadavek je p edán rodi ovskému class-loaderu, pokud není nalezen, poºadavek selhal. 17

KAPITOLA 3. OSGI SERVICE PLATFORM 2. Jestli je zdroj v boot delagation listu (org.osgi.framework.bootdelegation), je poºadavek p edán rodi ovskému class-loaderu, pokud je nalezen, hledání úsp ²n kon í. 3. Jestli je zdroj v balí ku importovaném pomocí Import-Package (nebo byl importován dynamicky) v p edchozím loadování, je poºadavek p edán class-loaderu exportujícího bundlu. Pokud není nalezen, poºadavek selhal. 4. Pokud je zdroj v balí ku importovaném z jiných bundl, je poºadavek p edán t mto bundl m. Jestli není nalezen, pokra uje se dal²ím krokem. 5. Prohledání vno ené classpath bundlu. Pokud zdroj není nalezen, p echází se na dal²í krok. 6. Pokud je zdroj v balí ku exportovaném bundlem nebo importovaném bundlem, hledání kon í neúsp chem. 7. Pokud je v balí ku importovaném dynamicky, je dynamický import proveden. Kdyº je nalezen exporter, naváºe se spojení, jinak poºadavek selhal. 8. Kdyº je dynamický import proveden, poºadavek je p edán exporteru, v jiném p ípad poºadavek selhal. 3.2.2.5 Lokalizace D leºitou schopností OSGi frameworku je práce s vícejazy nými bundly. Je moºné vytvo it celou aplikaci v jednom i více jazycích s velice jednoduchým dodáváním dal²ích jazykových mutací p idáním textových souboru do JAR archivu bundlu, nebo nejlépe do fragmentu vytvo eného speciáln pro tento ú el. Lokaliza ní soubory mají stejné základní jméno, za které se p idávají suxy denované v java.util.locale (language, country, variant) a ukon ují se koncovkou.properties. Framework hledá správný lokaliza ní soubor p idáváním sux k základnímu jménu podle specikovaného locale postupn se zobec uje dokud se nenajde konkrétní verze. 1 OSGI INF/ l10n /bundle_en_gb_welsh. p r o p e r t i e s 2 OSGI INF/ l10n /bundle_en_gb. p r o p e r t i e s 3 OSGI INF/ l10n /bundle_en. p r o p e r t i e s 4 OSGI INF/ l10n /bundle. p r o p e r t i e s Ukázka 3.1: Lokaliza ní soubory 18

3.2. OSGI FRAMEWORK Obrázek 3.6: Diagram na ítání t íd 19

KAPITOLA 3. OSGI SERVICE PLATFORM 3.2.2.6 Fragmenty Fragmenty jsou takové bundly, které mohou být frameworkem p ipojeny k jednomu nebo n kolika hostujícím bundl m. Toto p ipojování je sou ástí resolvingu. Oproti klasickým bundl m nemají fragmenty vlastní class-loader. Mají v²ak svou vlastní doménu ochrany. Vyuºívají se p edev²ím pro ukládání lokaliza ních soubor. Jazykové mutace se pak dají dodávat bez zásahu do hlavních bundl. 3.2.2.7 Extension Bundles Extension bundly nejsou klasické moduly tvo ící aplikaci, ale jedná se o roz²i ující ásti vlastního frameworku. Implementace OSGi frameworku nemusí být úplná, n které nepovinné ásti mohou z stat neimplementované a díky extension bundl m je moºné tyto ásti k frameworku dodat. Oproti oby ejným bundl m se v manifestu nemohou objevovat následující hlavi ky: Import-Package, Require-Bundle, Bundle-NativeCode, DynamicImport-Package, Bundle-Activator. 3.2.3 Life Cycle Layer Vrstva ºivotního cyklu se stará o správu bundl ve vrstv modul, jako je jejich instalace, odinstalace, aktualizace, aktivace a deaktivace. Tato vrstva obsahuje následující typy objekt : Bundle nainstalovaný bundle ve frameworku, Bundle Context rámec pro p ístup k bundl m, Bundle Activator objekt pro provedení akcí p i startu a zastavení bundlu, Bundle Event signál zna ící zm nu na bundlu, Framework Event signál zna ící zm nu na frameworku, Bundle Listener nasloucháva zm n bundlu, 20

3.2. OSGI FRAMEWORK Synchronous Bundle Listener synchronizovaný nasloucháva zm n bundlu, Framework Listener nasloucháva zm n frameworku, Bundle Exception vyjímka p i pádu frameworkových operací, System Bundle bundle reprezentující framework, Framework framework, Framework Factory továrna pro vytvá ení frameworku. 3.2.4 Service Layer Service layer je komunika ní vrstvou úzce spojenou s life cycle layer. Sluºba (service) je libovolný Java objekt registrovaný pod jedním i více jmény (v t²inou název rozhraní) ve speciálním seznamu. Kaºdý bundle m ºe registrovat vlastní sluºby, které jsou poté p ístupné v²em ostatním bundl m. Vrstva sluºeb obsahuje následující entity: Service objekt registrovaný v seznamu sluºeb, Service Registry seznam sluºeb, Service Reference odkaz na sluºbu (umoº uje p ístup k vlastnostem sluºby, ne v²ak k ní samotné), Service Registration objekt získaný p i úsp ²né registraci sluºby slouºící k aktualizaci vlastností sluºby a její odinstalaci, Service Permission práva umoº ující uºívat ur itá rozhraní k registraci i získávání sluºeb, Service Factory m ºe být zaregistrováno místo vlastní sluºby a tu pak vytvo it pro bundle, který si sluºbu vyºádá, Service Listener nasloucha událostí o sluºbách, Service Event událost pro registraci, modikaci i odstran ní sluºby, Filter objekt umoº ující ltraci sluºeb podle jejich vlastností, Invalid Syntax Exception výjimka pro chybu v syntaxi ltra ního výrazu. 21

KAPITOLA 3. OSGI SERVICE PLATFORM 3.3 Minimální bundle Denování minimálního obsahu bundlu je velice jednoduché. Jediné, co musí JAR archiv reprezentující bundle obsahovat, je soubor META-INF/MANIFEST.MF a ten m ºe být prázdný. Prázdný bundle se v²ak p íli² asto nepouºívá, a tak m ºeme za minimální verzi povaºovat bundle obsahující pouze aktivátor a manifest. Do takového manifestu uº je t eba p idat dv hlavi ky, a to Import-Package a Bundle-Activator. Je v²ak dobrým zvykem, tém aº povinností, aby manifest obsahoval i dal²í hlavi ky popisující bundle. Adresá ová struktura takového bundlu je vid t na ukázce 3.2, zdrojový kód na 3.3 a manifest zobrazuje 3.4. 1 sample. minimal. j a r 2 + sample 3 \ minimal 4 \ Activator. class 5 6 + META INF 7 \ MANIFEST.MF Ukázka 3.2: Adresá ová struktura minimálního bundlu 1 package sample. minimal ; 2 3 import org. o s g i. framework. BundleActivator ; 4 import org. o s g i. framework. BundleContext ; 5 6 public class Activator implements BundleActivator { 7 public void s t a r t ( BundleContext context ) throws Exception {} 8 public void stop ( BundleContext c o n t e x t ) throws Exception {} 9 } Ukázka 3.3: Aktivátor bundlu 1 Manifest Version : 1. 0 2 Bundle ManifestVersion : 2 3 Bundle Name: sample. minimal 4 Bundle SymbolicName : sample. minimal 5 Bundle Version : 1. 0. 0 6 Bundle Activator : sample. minimal. Activator 7 Import Package : org. o s g i. framework Ukázka 3.4: P íklad manifestu minimálního bundlu 22

3.4. IMPLEMENTACE OSGI 3.4 Implementace OSGi Díky faktu, ºe je OSGi Service Platform otev enou specikací, existuje mnoºství implementací, z nichº n které jsou úpln j²í neº jiné. Mnoho spole ností má své vlastní implementace, ale pro vývojá e jsou nejd leºit j²í ty voln dostupné nebo dokonce s otev enými zdrojovými kódy (open-source). Proto se v této sekci objeví pouze n které významn j²í voln dostupné implementace OSGi frameworku. Nyní je tou nejlep²í pravd podobn Equinox, která je vyvíjená spole ností The Eclipse Foundation. 3.4.1 Eclipse Equinox Spole nost The Eclipse Foundation si vyty ila cíl vytvo it plnou implementaci OSGi Core Framework R4 specikace. Krom jádra frameworku vytvo ila také mnoho bundl implementujících volitelné OSGi sluºby. Na technologii OSGi je postaveno i vývojové prost edí Eclipse IDE a platforma Eclipse RCP. 3.4.2 Apache Felix Apache Felix 5 je skupina projekt souvisejících s OSGi R4 platformou vznikající pod Apache licencí. Felix oproti Equinoxu implementuje mén volitelných ástí OSGi specikace. 3.4.3 Concierge Concierge 6 je velice kompaktní (velikost asi 80 kb) implementace t etího vydání OSGi speci- kace. Díky své velikosti je vhodná pro mobilní za ízení. Z malé velikosti JAR archivu frameworku také vyplývá, ºe nejde ani zdaleka o kompletní implementaci a volitelné ásti speci- kace jsou zcela vynechány. 3.4.4 JBoss Od verze 7 je JBoss 7 aplika ní server kompatibilní s OSGi specikací. Je tedy moºné vytvá et a nasazovat aplikace v podob OSGi bundl. Proti Equinoxu a Felixu jde o mén rozsáhlou implementaci. 5 felix.apache.org 6 concierge.sourceforge.net 7 www.jboss.org 23

KAPITOLA 3. OSGI SERVICE PLATFORM 3.4.5 Knopersh Knoplersh 8 je spole nost od²t pená od Gatespace, která byla jedním ze spoluzakladatel OSGi Alliance. Kdyº se v roce 2003 Gatespace rozhodla vydat svou implementaci OSGi frameworku jako open-source, byl vytvo en projekt Knoplersh. Implementované ásti jsou podobné jako ty obsaºené v následujícím projektu ProSyst. 3.4.6 ProSyst Spole nost ProSyst 9 se aktivn podílela na vytvá ení OSGi specikací jiº od prvního vydání. Nabízí implementace p edev²ím pro mobilní za ízení a rozsáhlostí je tém srovnatelná s produkty od Apache a Eclipse. 8 www.knopersh.org 9 www.prosyst.com 24

Kapitola 4 Modularita bez OSGi Vytvá ení modulárních aplikací není vázáno pouze na OSGi a jazyk Java, ale lze pouºívat i jiné frameworky a programovací jazyky. V této kapitole bude uvedeno n kolik modulárních systém pro jazyky Java, C a C++. Jazyk Java byl vybrán kv li souvislosti s tématem této práce a C++ byl zvolen jako jeho nejv t²í konkurent. Jazyk C bude zmín n spí²e pro zajímavost. 4.1 Java Plug-in Framework JPF 1 neboli Java Plug-in Framework je open-source knihovna pro vývoj modulárních aplikací v jazyce Java. Základem tohoto frameworku je modulární systém Eclipse platformy z roku 2004, kdy v Eclipse je²t nebyl uºíván OSGi framework. P estoºe si JPF pluginy byly velmi podobné s Eclipse moduly, nebyly kompatibilní. Stejn jako OSGi bundly i JPF pluginy pouºívají manifest k uchovávání informací o modulu. Naopak stejn jako Eclipse platforma pouºívá JPF systém extension point extension, v emº je znatelný stejný základ obou knihoven. 4.2 Java Simple Plugin Framework Dal²ím frameworkem pro jazyk Java je JSPF 2 Java Simple Plugin Framework. Vytvá ení plugin pro tento modulární systém je zaloºeno na Java anotacích a není t eba k nim p ikládat ºádné dal²í soubory. Informace o pluginu nejsou uloºeny v manifestu jako u OSGi nebo JPF, ani v ºádném jiném kongura ním souboru. 1 jpf.sourceforge.net 2 code.google.com/p/jspf 25

KAPITOLA 4. MODULARITA BEZ OSGI 4.3 jin-plugin Jin-plugin 3 je jednoduchý systém vyvinutý práv proto, ºe jsou ostatní existující frameworky typu OSGi a JPF p íli² komplexní pro n které jednoduché modulární aplikace. Jin-plugin je dostupný pro programovací jazyk Java, ale také pro skriptovací jazyk PHP. Plugin je v tomto systému reprezentován adresá em obsahujícím, mimo pot ebný kompilovaný kód, kongura ní soubor plugin.yaml. 4.4 NetBeans Platform Modular Runtime Container NetBeans Runtime Container 4 je modulární systém pro NetBeans platformu. Zjevn se jedná o framework pro programovací jazyk Java, jenº je z jednoho pohledu velmi podobný OSGi, na druhou stranu jsou tyto systémy absolutn odli²né. Oba frameworky pouºívají pro uchovávání specikace modulu soubor MANIFEST.MF obsahující hlavi ky podobného významu. Odli²nost v²ak p ichází hlavn s pojmenováním jednotlivých poloºek v manifestu a samoz ejm s rozdílnými (ne p íli², z pohledu návrhu) API. Schopnost t chto navzájem nekompatibilních systém pracovat spole n dokazuje existence API m stku Netigso (viz 5.2.1). 4.5 C-Plu C-Plu 5 je pluginovací systém pro programovací jazyk C, jenº byl zna n inspirován p vodním modulárním systémem Eclipse platformy. Stejn jako framework JPF p evzal systém extension point extension poskytující zp sob roz²i ování hlavního programu. Informace o modulu jsou umíst ny v XML souboru plugin.xml, který se musí nacházet v adresá i s binárními soubory pluginu. 4.6 Qt Plugins Qt framework 6 je pravd podobn nejlep²í cross-platformní knihovnou pro vývoj nejen grackých C++ aplikací, který je pro tvorbu nekomer ního software poskytován zdarma. P i programování Qt kódu je z ejmé, ºe je celý framework inspirován jazykem Java a v n kterých ástech dokonce sv j vzor p ed í. 3 code.google.com/p/jin-plugin 4 netbeans.org/features/platform 5 www.c-plu.org 6 qt.nokia.com/products 26

4.7. PLUG V Qt frameworku je moºné vytvá et dva druhy plugin, a to roz²i ující vlastní framework a roz²i ující Qt aplikace. S tématem tohoto dokumentu souvisí spí²e druhý typ plugin, jejichº vývoj je o n co sloºit j²í, protoºe mohou být absolutn obecné, zatímco moduly roz²i ující framework jako takový mohou být jen n kolika druh a Qt obsahuje metody na jejich zpracování. Qt pluginy nativn neobsahují ºádný nástroj pro uchovávání d leºitých informací, jako je tomu nap. u OSGi. Framework je o pluginu informován pouze pomocí n kolika denovaných maker, která v²ak nemají schopnost p edávat také vlastnosti pluginu, jako je verze, jméno, autor atd. 4.7 Plug Plug 7 je open-source pluginovací systém pro jazyk C++. Oproti Qt frameworku obsahuje také nástroje pro správu verzí jednotlivých plugin, jejichº absence u Qt je zna nou nevýhodou. Informace o pluginu jsou uchovávány ve vlastním C++ kódu. Registrace plugin se provádí v souboru.cpp ve funkci registerplugin, to znamená, ºe se p i p idání nového pluginu musí tento soubor pozm nit a p ekompilovat. Tím vznikne binární soubor distribuovaný s pluginem jako DLL 8 knihovna. 4.8 Pluma Pluma 9 je dal²ím open-source projektem, který poskytuje modulární systém pro jazyk C++. Stejn jako p edchozí framework obsahuje správu verzí, ale jako Qt pouºívá k registraci plugin a dal²ím akcím makra. Ze zmín ných pluginovacích systém pro jazyk C++ se tento zdá být nejpouºiteln j²í. 7 pugg.sourceforge.net 8 DLL je zkratkou pro Dynamic-link library (dynamicky linkovaná knihovna). 9 pluma-framework.sourceforge.net 27

28 KAPITOLA 4. MODULARITA BEZ OSGI

Kapitola 5 Rich Client Platform Jelikoº si je v t²ina aplikací navzájem velice podobná, není nutné je vºdy vyvíjet celé od za átku, ale je moºné postavit je na stejné kost e poskytující správu oken, plugin, nabídek, nápov dy atd. Práv takovou kostru nabízejí RCP systémy, jako je Eclipse RCP i NetBeans RCP. Jedná se o open-source projekty vzniklé p vodn z vývojových prost edí. 5.1 Eclipse RCP Eclipse Rich Client Platform vznikla v roce 2004 z p vodn jednostranné aplikace Eclipse IDE. Ta je vyuºívána pro vývoj aplikací v r zných programovacích jazycích. Po vzniku Eclipse RCP mohou vývojá i tvo it jakékoliv profesionální aplikace na základ této platformy. Platforma Eclipse (verze 3.7) je zaloºena na pluginové architektu e pouºívající vlastní opensource implementaci OSGi frameworku zvanou Equinox. Nejmen²í instalovatelnou jednotkou je plugin, coº je v Eclipse RCP jiný název pro OSGi bundle. Aplikace zaloºená na této platform se skládá z runtime prost edí neboli OSGi frameworku starajícího se o správu plugin a ástí k vykreslování grackého rozhraní a jeho ízení. Znázorn ní komponent, z nichº se platforma skládá, je moºné vid t na obrázku 5.1 staºeném z [9]. Jak je patrno z této ilustrace, krom runtime prost edí a platformových plugin se Eclipse RCP skládá ze t í dal²ích ástí, jimiº jsou SWT, JFace a Workbench. SWT je nízkoúrov ovou grackou knihovnou pro vykreslování základních komponent UI (uºivatelského rozhraní), jako jsou tla ítka, nabídky, písma atd. Tato knihovna není nijak závislá na Eclipse platform a lze jí pouºít i v jiných aplikacích. Základním cílem SWT je vyuºívat systémové gracké prvky, jak jen je to moºné. Díky tomuto faktu, aplikace vyuºívající SWT p irozen zapadají do vzhledu sytému, na kterém jsou spu²t ny. 29

KAPITOLA 5. RICH CLIENT PLATFORM Obrázek 5.1: Komponenty Eclipse RCP JFace vyuºívá SWT pro vykreslování sloºit j²ích komponent uºivatelského rozhraní. Eclipse aplikace jsou z UI pohledu sloºeny práv z t chto komponent. Workbench je dal²í vrstvou nacházející se nad JFace poskytující koordinaci a roz²i itelnost UI komponent. Jedná se hlavn o poskytování extension points (viz 5.1.2.1) a správu perspektiv (perspective). Z pohledu uºivatele se workbench jeví jako skupina oken uspo ádaných do poºadovaného rozestav ní (layout). V Eclipse platform je oknem bu pohled (view), nebo editor. Tato okna je moºné uvnit perspektivy (kontejner obsahující okna v ur itém layoutu) p emis ovat podle pot eby. 5.1.1 Struktura zdrojových kódu Vývoj aplikace zaloºené na Eclipse platform je vývojem OSGi bundl je t eba dodrºovat pravidla nutná k jejich správné funkci. Nutností je hlavn p ítomnost souboru MANIFEST.MF a jeho správná struktura. Krom tohoto souboru je je²t t eba vytvo it plugin.xml, v n mº se nacházejí denice roz²í ení (extensions). Pro vytvo ení základu aplikace je vhodné pouºít ²ablonu (nap. "Hello World") poskytovanou vývojovým prost edím Eclipse IDE. Minimální Eclipse RCP aplikace obsahuje implementace následujících t íd a rozhraní, které jsou vygenerovány vývojovým prost edím jako sou ást zmín né ²ablony: AbstractUIPlugin jde o ekvivalent oby ejného BundleActivator. Application stará se o spu²t ní aplikace jako metoda main v klasických Java programech. V implementaci metody start se spou²tí vlastní uºivatelské rozhraní pomocí metody PlatformUI.createAndRunWorkbench. Tato t ída musí být denována jako extension v souboru plugin.xml zp sobem uvedeným v ukázce 5.1. WorkbenchAdvisor implementace této abstraktní t ídy je jako objekt p edána do metody PlatformUI.createAndRunWorkbench zmín né vý²e. Tato t ída denuje po áte ní 30

5.1. ECLIPSE RCP perspektivu, která se má pouºít, a také vytvá í objekt typu WorkbenchWindowAdvisor denující podobu hlavního okna aplikace. IPerspectiveFactory toto rozhraní je t eba implementovat pro denování inicializa ní perspektivy aplikace. T ída se musí zaregistrovat do plugin.xml souboru jak ukazuje 5.2. WorkbenchWindowAdvisor t ída umoº ující nastavovat podobu oken aplikace implementací metody prewindowopen. ActionBarAdvisor objekt tohoto typu je vracen metodou createactionbaradvisor t ídy WorkbenchWindowAdvisor a jeho úkolem je denovat podobu hlavní nabídky p íslu²ného okna. 1 <extension id=" a p p l i c a t i o n " point=" org. e c l i p s e. core. runtime. a p p l i c a t i o n s "> 2 <application > 3 <run c l a s s=" cz. cvut. fsv. e c l i p s e. sample. Application "></run> 4 </application > 5 </extension > Ukázka 5.1: Denice roz²í ení applications 1 <extension point=" org. e c l i p s e. ui. p e r s p e c t i v e s "> 2 <perspective 3 name="sample Perspective " 4 c l a s s=" cz. cvut. fsv. e c l i p s e. sample. Perspective " 5 id=" cz. cvut. fsv. e c l i p s e. sample. p erspective "> 6 </perspective > 7 </extension > Ukázka 5.2: Denice roz²í ení perspectives 5.1.2 Workbench Jak jiº bylo zmín no, workbench je správcem oken, nabídek a nástrojových li²t. Práv tato vrstva d lá Eclipse RCP tím ím je platformou, díky níº je vývojá schopen vytvo it bohatou a jednodu²e roz²i itelnou aplikaci. Workbench poskytuje p es 50 extension bod a víc jak 350 t íd API. Základní funkcionalitou se bude zabývat práv tato sekce. 5.1.2.1 Extension body Systém extension bod a vlastních roz²í ení je vytvo en pro snadnou roz²i itelnost aplikací pomocí plugin, které mohou denovat nap íklad nové nabídky, li²ty nástroj atd. Extension body jsou denované v takzvaných schématech, které jsou reprezentovány XML souborem 31

KAPITOLA 5. RICH CLIENT PLATFORM s p íponou exsd. Toto schéma je vºdy pot eba registrovat v souboru plugin.xml, jak je ukázáno v 5.3. P i vytvá ení schématu je vhodné pouºít podporu Eclipse IDE a postupovat nap íklad podle online tutoriálu [8]. 1 <extension point 2 id="sample. transformation " 3 name=" Transformation " 4 schema="schema/ transformation. exsd "/> Ukázka 5.3: Registrace schématu extension bod Plugin, jenº poskytuje extension bod, je také zodpov dný za zpracování v²ech roz²í ení tohoto bodu. Nezáleºí na tom, kde plugin toto vyhodnocení provede, ale je z ejmé, ºe developer musí toto místo ur it podle typu pluginu a jeho funkcionality. P íklad takového kódu je uveden v ukázce 5.4. 1 private void handleextensions () { 2 IConfigurationElement [ ] c o n f i g = Platform. getextensionregistry () 3. getconfigurationelementsfor ( "sample. transformation " ) ; 4 try { 5 for ( IConfigurationElement e : c o n f i g ) { 6 Object o = e. createexecutableextension ( " transformator " ) ; 7 i f ( o instanceof ITransformation ) { 8 System. out. p r i n t l n ( ( ( ITransformation ) o ). getname () ) ; 9 } 10 } 11 } catch ( CoreException ex ) { 12 System. out. p r i n t l n ( ex. getmessage () ) ; 13 } 14 } Ukázka 5.4: Zpracování roz²í ení Díky denici extension bodu je moºné obohatit funkce aplikace pomocí roz²í ení, které se na tento bod napojí. Spojení je denováno v souboru plugin.xml zp sobem, jaký je demonstrován v ukázkách 5.1 a 5.2. 5.1.2.2 Advisors Jak jiº název napovídá, advisors jsou rádcové workbenche v oblasti vzhledu a chování uºivatelského rozhraní aplikace. Existují t i typy advisor, jejichº jména samy o sob íkají, eho se týkají. Tyto typy jsou ekvivalentem t íd: WorkbenchAdvisor má na starosti akce spojené s aplikací jako takovou (spu²t ní, ukon ování). WorkbenchWindowAdvisor je vytvo en pro kaºdé okno aplikace zvlá² a tomuto oknu íká, jaké nabídky má obsahovat, nebo kde a jak veliké se má objevit. 32

5.1. ECLIPSE RCP ActionBarAdvisor napovídá svému oknu, jaké akce mají obsahovat jeho li²ty nástroj i nabídky. 5.1.2.3 šivotní cyklus V t²ina aplikací vlastní jednu sadu advisor, které spolu spolupracují, jak je ukázáno na obrázku 5.2 zkopírovaném z [3] a mírn upraveném. Obrázek 5.2: šivotní cyklus workbenche Na tomto diagramu je z eteln vid t, jak se metody postupn volají a programátor je schopen pomocí jejich p epsání 1 zasahovat do b hu aplikace na p esn specikovaných místech. 1 P epsání metody (method overriding) je schopnost objektov orientovaného programování umoº ující dce iným t ídám m nit nápl metod svých rodi. 33

KAPITOLA 5. RICH CLIENT PLATFORM 5.1.2.4 Perspektivy D leºitou ástí Eclipse platformy je správa vnit ních oken aplikace. Tato okna se nazývají pohledy a editory, zatímco kontejneru ur ujícímu jejich rozestav ní a chování se íká perspektiva. Souvislost t chto t í komponent spolu s dal²ími prvky uºivatelského rozhraní je vyobrazena na diagramu 5.3 op t p evzatém z [3]. Obrázek 5.3: Souvislost pohled, editor a perspektiv Perspektivy se pouºívají k rozli²ení uspo ádání vnit ních oken aplikace podle práv provád né práce uºivatelem. Jiných oken a jejich rozestav ní je nap íklad pot eba p i lad ní zdrojového kódu, oproti prolování, i samotnému vyvíjení. K registraci nové perspektivy se vyuºívá extension bod org.eclipse.ui.perspectives a vytvo ení podoby layoutu se provádí v IPerspectiveFactory.createInitialLayout. P íklad kódu perspektivy s dv ma r znými pohledy je znázorn n v ukázce 5.5 a na obrázku 5.4 je vid t tato perspektiva p ímo v ukázkové aplikaci. Pohledy z tohoto p íkladu FirstView a SecondView musí být zaregistrovány v souboru plugin.xml pomocí extension bodu org.eclipse.ui.views (viz 5.1.2.5). Uvnit jedné perspektivy je moºné otev ít víckrát jeden pohled, pokud má v denici nastaven atribut enablemultiple na true. Jelikoº ID pohledu musí být unikátní, existuje systém primárního a sekundárního identikátoru. Primární ID z stává totoºné s ID pohledu, ale p idá se k n mu sekundární identikátor, jenº musí být uvnit perspektivy jednozna ný. Upravený p íklad s dv ma r znými pohledy na dva totoºné je vid t na ukázce 5.6. Pro zobrazení nástrojové li²ty s p epína em dostupných perspektiv (p epína je vid t na obrázku 5.4) sta í zavolat IWorkbenchWindowConfigurer.setShowPerspectiveBar(true) p ed otev ením okna, tudíº v metod WorkbenchWindowAdvisor.preWindowOpen. Podobn lze také docílit vytvo ení nabídky perspektiv, a to zp sobem ukázaným v p íkladu 5.7. 34

5.1. ECLIPSE RCP 1 public class TwoViewsPerspective implements IPerspectiveFactory { 2 public void c r e a t e I n i t i a l L a y o u t ( IPageLayout layout ) { 3 layout. addview ( FirstView. ID, 4 IPageLayout.LEFT, 5 0.33 f, 6 layout. geteditorarea () ) ; 7 layout. addview ( SecondView. ID, 8 IPageLayout.BOTTOM, 9 0.5 f, 10 layout. geteditorarea () ) ; 11 } 12 } Ukázka 5.5: P íklad vytvo ení perspektivy se dv ma r znými pohledy Obrázek 5.4: Ukázka perspektivy s dv ma pohledy 1 public class OneViewTwicePerspective implements IPerspectiveFactory { 2 public void c r e a t e I n i t i a l L a y o u t ( IPageLayout layout ) { 3 layout. addview ( SampleView. ID + " :1 ",... ) ; 4 layout. addview ( SampleView. ID + " :2 ",... ) ; 5 } 6 } Ukázka 5.6: P íklad vytvo ení perspektivy se dv ma stejnými pohledy Perspektivy je moºné spravovat také vlastním kódem, k emuº slouºí objekt typu IPerspectiveRegistry p ístupný z workbenche nap íklad pomocí metody PlatformUI.getWorkbench().getPerspectiveRegistry(). Tento registr obsahuje v²echny perspektivy dosaºitelné pomocí unikátního identika ního ísla. Mimo jiné, k otvírání a zavírání perspektiv slouºí t ída IWorkbenchPage a k odchytávání zm n je moºno pouºít IPerspectiveListener (krom tohoto existují t i dal²í listenery: IPerspectiveListener2, IPerspectiveListener3, IPerspectiveListener4). 35

KAPITOLA 5. RICH CLIENT PLATFORM 1 public c l a s s ApplicationActionBarAdvisor extends ActionBarAdvisor { 2 private IContributionItem p e r s p e c t i v e s ; 3 4 public ApplicationActionBarAdvisor ( IActionBarConfigurer c o n f i g u r e r ) { 5 super ( c o n f i g u r e r ) ; 6 } 7 protected void makeactions ( IWorkbenchWindow window) { 8 p e r s p e c t i v e s = ContributionItemFactory 9.PERSPECTIVES_SHORTLIST. create (window) ; 10 } 11 protected void fillmenubar ( IMenuManager menubar) { 12 MenuManager layoutmenu = new MenuManager( "Switch Layout", " layout " ) ; 13 layoutmenu. add ( p e r s p e c t i v e s ) ; 14 menubar. add ( layoutmenu ) ; 15 } 16 } Ukázka 5.7: P idání nabídky pro p epínání perspektiv 5.1.2.5 Pohledy a editory Pohledy a editory jsou vnit ní okna aplikace vyuºívající Eclipse platformu. Je mezi nimi n kolik rozdíl, ten hlavní je spí²e lozocký. Editory jsou hlavními okny celé aplikace, na n º se po v t²inu uºivatelovi práce soust edí jeho pozornost, zatímco pohledy obsahují dopl ující informace i navigaci. V Eclipse IDE je editorem oblast pro psaní kódu a pohledem nap íklad výstupní konzole nebo okno s otev enými projekty. Dal²í odli²nosti jsou uvedeny v následujícím seznamu: editory jsou sdíleny perspektivami (pokud je editor v jedné perspektiv otev en, je otev en i v t ch ostatních), editory a pohledy nemohou být najednou ve stejném balí ku (nejedná se o Java balí ek package, ale o uskupení oken aplikace stack), pohledy nemohou být oddokovány z hlavního okna aplikace, editory musí mít titulek, pohledy mají vlastní nástrojové li²ty a nabídky. Pro vytvá ení vlastních pohled a editor se vyuºívá t íd ViewPart a EditorPart, kterým je zapot ebí implementovat abstraktní metody. Dal²í nutností je registrace do souboru plugin.xml (p íklad 5.8). Na rozdíl od pohled, editory jsou spou²t ny takzvanými editor inputy implementace rozhraní IEditorInput. Tento model spou²t ní byl zaveden kv li zlep²ení výkonu Eclipse RCP aplikací. Jelikoº objekty reprezentující vlastní editory jsou objemn j²í neº jejich inputy, 36

5.1. ECLIPSE RCP 1 <extension point=" org. e c l i p s e. ui. views "> 2 <view 3 id=" cz. cvut. fsv. e c l i p s e. sample. sampleview" 4 c l a s s=" cz. cvut. fsv. e c l i p s e. sample. SampleView" 5 name="sample View"> 6 </view> 7 </extension > 8 9 <extension point=" org. e c l i p s e. ui. e d i t o r s "> 10 <e d i t o r 11 id=" cz. cvut. fsv. e c l i p s e. sample. sampleeditor " 12 c l a s s=" cz. cvut. fsv. e c l i p s e. sample. SampleEditor " 13 name="sample Editor "> 14 </editor > 15 </extension > Ukázka 5.8: Registrace pohledu a editoru 1 IEditorInput input = new SampleInput () ; 2 PlatformUI. getworkbench () 3. getactiveworkbenchwindow () 4. getactivepage () 5. openeditor ( input, SampleEditor. ID) ; Ukázka 5.9: Otev ení editoru pomocí editor inputu je vhodné získávat informace o budoucím editoru skrz jiný objekt, kterým je práv input. Otev ení editoru se provádí tak, jak je vid t na ukázce 5.9. Podobn jako se v ukázce 5.7 vytvá ela nabídka perspektiv, je moºné vytvo it menu pohled vyuºitím metody ContributionItemFactory.VIEWS_SHORTLIST.create. P ístup k pohled m jako takovým poskytuje metoda workbenche getviewregistry. 5.1.2.6 Akce Akce jsou p esn to, co íká jejich název. Jedná se o spojení jisté innosti provád né aplikací s elementem grackého rozhraní. Pokud uºivatel klikne na poloºku v menu, provede se akce touto poloºkou reprezentovaná. P i vytvá ení akce musí programátor rozhodnout o jejím umíst ní, vzhledu a chování. Akce je moºné vytvá et v kódu aplikace (metoda ActionBarAdvisor.fillMenuBar), coº je vhodné hlavn u drobných program, u kterých se nepo ítá s dal²ím roz²i ováním. V t²í aplikace musí po ítat s moºnou roz²i itelností pomocí plugin a je u nich vhodn j²í vyuºít deklarativní vytvá ení akcí (oba zp soby se dají samoz ejm kombinovat). Takové akce se denují p es extension body v souborech plugin.xml a jejich výhody jsou: dostupnost v uºivatelském prost edí bez spu²t ní vlastního pluginu, 37

KAPITOLA 5. RICH CLIENT PLATFORM moºnost spojovat akce s perspektivami a tím vytvá et dynamické nabídky a li²ty, poskytují uºivateli schopnost upravovat nabídky a li²ty. Workbench poskytuje n kolik základních akcí pouºitelných ve v t²in aplikací. Jsou denované jako inner t ídy v ActionFactory a pat í mezi n nap íklad QUIT, SAVE nebo ABOUT. Ukázka 5.10 znázor uje vytvo ení menu s názvem About menu v kódu aplikace. Jak takové menu vypadá je vid t na obrázku 5.5. 1 protected void fillmenubar ( IMenuManager menubar) { 2 MenuManager helpmenu = new MenuManager( "About menu", " about" ) ; 3 helpmenu. add ( ActionFactory.ABOUT. create (window) ) ; 4 helpmenu. add (new Separator () ) ; 5 helpmenu. add ( ActionFactory.HELP_CONTENTS. create (window) ) ; 6 menubar. add ( helpmenu ) ; 7 } Ukázka 5.10: Akce vytvá ené v kódu aplikace Obrázek 5.5: P íklad menu Shodn vypadající menu jako je na obrázku 5.5 se dá vytvo it pouze pomocí souboru plugin.xml, jak znázor uje ukázka 5.11. Problémem tohoto e²ení je nutnost implementace t íd obsluhující jednotlivé akce nelze pouºít základní akce workbenche jako v p edchozí ukázce. Tuto závadu e²í pouºití p íkaz, popsané v následující sekci 5.1.2.7. 5.1.2.7 P íkazy P íkazy a akce jsou z funk ního hlediska to samé. Framework akcí byl d íve a je moºné, ºe asem úpln zastará a nebude se jiº pouºívat. Nyní je v²ak moºné pouºívat jak akce, tak p íkazy. Pomocí p íkaz se dají jednodu²e pouºívat i základní akce workbenche v plugin.xml souboru. XML kód vytvá ející menu zobrazené na obrázku 5.5 je k vid ní na ukázce 5.12. Na t etí ádce této ukázky je vid t atribut locationuri tagu menucontribution, který se stará o umíst ní vznikající nabídky. Tato adresa se skládá ze t í ástí: 38

5.1. ECLIPSE RCP 1 <extension point=" org. e c l i p s e. ui. actionsets "> 2 <actionset id="sample. actionset " 3 l a b e l="sample ActionSet " 4 v i s i b l e=" true "> 5 <action id="sample. about" 6 c l a s s="sample. AboutAction" 7 l a b e l="& About" 8 menubarpath="sample. menu. about/ separator1 " 9 s t a t e=" true " 10 s t y l e="push"> 11 </action> 12 <action id="sample. action. help " 13 c l a s s="sample. HelpAction " 14 l a b e l="& Help Contents " 15 menubarpath="sample. menu. about/ separator2 " 16 s t y l e="push"> 17 </action> 18 <menu id="sample. menu. about" 19 l a b e l="about menu"> 20 <separator name=" separator1 " /> 21 <separator name=" separator2 " /> 22 </menu> 23 </actionset > 24 </extension > Ukázka 5.11: Akce vytvá ené pomocí plugin.xml 1 <extension point=" org. e c l i p s e. ui. menus"> 2 <menucontribution 3 locationuri="menu : org. e c l i p s e. ui. main. menu? a f t e r=something " 4 allpopups=" f a l s e "> 5 <menu l a b e l="about menu"> 6 <command commandid=" org. e c l i p s e. ui. help. aboutaction " 7 l a b e l="& About" 8 s t y l e="push"> 9 </command> 10 <separator name="sample. separator1 " v i s i b l e=" true " /> 11 <command commandid=" org. e c l i p s e. ui. help. helpcontents " 12 l a b e l="& Help Contents" 13 s t y l e="push"> 14 </command> 15 </menu> 16 </menucontribution> 17 </extension > Ukázka 5.12: Menu vyuºívající základní akce pomocí p íkaz schéma ur uje typ nabídky a jde o jednu z hodnot menu, popup, toolbar, identikátor unikátní identikátor umíst ní, argumenty mohou udávat relativní polohu k jinému prvku ve shodném umíst ní. 39

KAPITOLA 5. RICH CLIENT PLATFORM Jako identikátor polohy je moºné pouºít n který z t ch poskytovaných platformou, jako jsou: org.eclipse.ui.main.menu hlavní nabídka okna, org.eclipse.ui.main.toolbar hlavní nástrojová li²ta okna, org.eclipse.ui.views.problemview pohled problém, org.eclipse.ui.views.contentoutline p ehledový pohled, org.eclipse.ui.popup.any jakákoliv vyskakovací nabídka. 5.2 NetBeans RCP Platforma vytvo ená p i vývoji NetBeans IDE 2 NetBeans RCP, je velice podobná té od Eclipse Foundation, ale obrovský rozdíl je v runtime prost edí. Eclipse pouºívá svou implementaci OSGi frameworku, zatímco NetBeans vyuºívá zcela vlastní pluginovací systém to znamená, ºe není p irozen kompatibilní s OSGi bundly. Vlastním programováním v NetBeans platform jsem se zabývala jiº ve své bakalá ské práci [1], proto ho zde nebudu dále analyzovat. 5.2.1 Netigso Jak bylo e eno vý²e, NetBeans p vodn nevyuºívá OSGi framework, ale má vlastní pluginovací systém zvaný NetBeans Modular Runtime Container. Pro moºnost vyuºívat také OSGi bundly byl vytvo en API m stek mezi t mito dv ma kontejnery zvaný Netigso. M stek umoº uje b h dvou nezávislých API vedle sebe a jejich vzájemnou komunikaci. Vedle Net- Beans kontejneru tedy b ºí implementace OSGi, a to Felix (viz. 3.4.2). Oba pluginovací systémy pouºívají k distribuci JAR archiv a k uchovávání informací o pluginu soubor META-INF/MANIFEST.MF uloºený práv ve zmín ném archivu. P i instalaci pluginu m stek rozhodne, o jaký druh se jedná a spustí ho v poºadovaném runtime kontejneru. Zárove vytvo í tzv. stínový plugin, jenº je registrován v druhém kontejneru. Díky tomuto systému je moºné k íºit závislosti plugin nezávisle na jejich druhu (nap. NetBeans modul m ºe být závislý na OSGi bundlu). Aby mohl tento API m stek vzniknout, muselo být provedeno pár zm n v obou pluginovacích systémech. To znamená, ºe musel být do Felixu p idán jistý patch pro zaji²t ní funkcionality. Tím pádem je Netigso závislé na Felixu a nem ºe vyuºívat jinou OSGi implementaci, pokud tato implementace také nep ijme zmín ný patch. Kompatibilitu hlavi ek manifestu ukazuje tabulka 5.1 áste n p evzatá z [7]. 2 netbeans.org 40

5.2. NETBEANS RCP NetBeans OSGi OpenIDE-Module: org.mymodule Bundle-SymbolicName: org.mymodule OpenIDE-Module-Specication-Version: 7.3 Bundle-Version: 7.3 OpenIDE-Module: org.mymodule/2 Bundle-SymbolicName: org.mymodule OpenIDE-Module-Specication-Version: 7.3 Bundle-Version: 207.3 OpenIDE-Module-Public-Packages: x.y.z Export-Package: x.y.z OpenIDE-Module-Module-Dependencies: another.module > 2.1 Require-Bundle: another.module; version="[2.1, 100.0)" OpenIDE-Module-Module-Dependencies: another.module/2 > 2.1 Require-Bundle: another.module; version="[202.1, 300.0)" OpenIDE-Module-Module-Dependencies: another.module/1-2 > 1.38 Require-Bundle: another.module; version="[101.38,300)" Tabulka 5.1: Hlavi ky manifestu 5.2.2 Netbinox Dce iným projektem Netigso je Netbinox. Jedná se o spojení NetBeans platformy s OSGi implementací Equinox (viz. 3.4.1) vytvá ející novou samostatnou implementaci. 41

KAPITOLA 5. RICH CLIENT PLATFORM 42

ćst III Realizace 43

Kapitola 6 Bundly V této kapitole bude nastín n vývoj plugin vyuºívajících OSGi technologii, tedy bundl. V základ se ukázkové bundly d lí na t i kategorie: poskytující API, zobrazující data a poskytující uºivatelské rozhraní. Postupn budou p edstaveny v²echny bundly t chto kategorií. P estoºe NetBeans IDE neobsahuje tém ºádnou podporu pro vývoj OSGi bundl, na rozdíl od Eclipse IDE, jehoº podpora je skute n bohatá, v²echny bundly krom základního modulu Eclipse RCP aplikace byly vyvíjeny práv v NetBeans IDE. Bylo tak u in no kv li rozdílnému chování vývojového prost edí jak z pohledu editoru, tak kompilace i správy projekt, coº se ukázalo jako jakási drobná brzda ve vývoji aplikací, kv li jiº zaºitým zvyk m v uºívání NetBeans IDE. 6.1 Bundly poskytující API Do této sekce spadá pouze jediný bundle core.api. Bylo moºné rozd lit t ídy do více modul, ale pro zachování jisté stru nosti ukázek a také kv li velmi malému rozsahu tohoto bundlu se tak nestalo. 6.1.1 core.api Tento bundle obsahuje n kolik základních t íd a rozhraní p eváºn pro denici pouºitelných sluºeb (services). Jedná se o následující ty i rozhraní umíst ny v balí ku cz.cvut.fsv.osgi.geoplug.core.api.services: CoordinatesParser pro vytvá ení parser s denovanou p íponou parserovaného souboru, DisplayCanvas toto rozhraní umoº uje zobrazení gracké komponenty pro vykreslení zadaného obsahu, 45

KAPITOLA 6. BUNDLY MenuAction v²echny registrované sluºby denované tímto rozhraním vytvá ejí hlavní nabídku aplikace (jde o potomka rozhraní ActionListener), OpenFileDialog poskytuje uºivatelské rozhraní k získávání soubor ke zpracování. Pokud n který bundle implementuje jedno ze zmín ných rozhraní, pro ádné pouºití je t eba implementovaný objekt zaregistrovat do seznamu dostupných sluºeb. Tím se docílí pouºitelnosti vzniklých t íd jinými bundly, které v registru sluºeb vyhledávají objekty spjaté s ur itými rozhraními. P íklad takové registrace objektu pro parserování sou adnic je ukázán v 6.1. 1 public void s t a r t ( BundleContext bc ) throws Exception { 2 Hashtable p r o p e r t i e s = new Hashtable () ; 3 p r o p e r t i e s. put ( " extension ", " csv " ) ; 4 bc. r e g i s t e r S e r v i c e ( CoordinatesParser. class. getname (), 5 new CSVCoordinateParser (), 6 p r o p e r t i e s ) ; 7 } Ukázka 6.1: Registrace sluºby CoordinatesParser Krom t chto rozhraní obsahuje bundle core.api je²t t ídu pro uchování 3D bodu s názvem Point3D a t ídu WMSUrl s abstraktní metodou buildurl, která se pouºívá k uchování dat a k jejich následnému vyuºití k vytvo ení URL pro webovou mapovou sluºbu. Vzhledem k tomu, ºe tento bundle denuje knihovnu pro ostatní bundly, je z ejmé, ºe musí své balí ky zve ejnit v souboru MANIFEST.MF pomocí hlavi ky Export-Package, jak znázor uje ukázka 6.2. 1 Export Package : cz. cvut. fsv. o s g i. geoplug. core. api. s e r v i c e s, 2 cz. cvut. fsv. o s g i. geoplug. core. api. coordinates, 3 cz. cvut. fsv. o s g i. geoplug. core. api. misc Ukázka 6.2: Zve ejn ní balí k knihovny core.api Ostatní bundly pak mohou t chto balí k vyuºívat, pokud v manifestu uvedou bu hlavi ku Import-Package s názvy poºadovaných balí k, nebo Require-Bundle ur ující import v²ech balí k, které bundle exportuje. 6.2 Bundly zobrazující data Pro názornou ukázku pouºívání zvolených platforem byly vybrány n které geoinformatické akce, jeº by grackého uºivatelského rozhraní mohly vyuºít. Proto byly jako vhodné p íklady zvoleny: zobrazování mapy získané p es WMS a velmi jednoduché vykreslování bod, které se pomocí CSV parseru na ítají ze souboru. 46

6.2. BUNDLY ZOBRAZUJÍCÍ DATA Vzhledem k faktu, ºe programový kód vytvá ející a spravující uºivatelské rozhraní je závislý na platform, jsou tyto zobrazující bundly spí²e zobrazova i grackých komponent, neº aby n jaké komponenty skute n obsahovaly. Pokud v aplikaci nebudou nainstalovány bundly poskytující uºivatelské rozhraní k zobrazování dat, jsou bundly popisované v této sekci zcela bezcenné. Dále do této sekce pat í je²t plugin zobrazující aktuáln nainstalované bundly. 6.2.1 display.bundles Bundle display.bundles je velice jednoduchým modulem obsahující pouze jednu t ídu, a to vlastní aktivátor. V metod Activator.start se provede registrace objektu vzniklého vyuºitím technologie anonymních t íd pod jméno rozhraní MenuAction. Tím vzniká poloºka v menu zobrazující dialogové okno s výpisem v²ech instalovaných bundl, který je moºný získat velmi jednoduchým zp sobem uvedeným v ukázce 6.3. 1 StringBuilder s t r = new StringBuilder () ; 2 for ( Bundle bundle : bundlecontext. getbundles () ) { 3 s t r. append ( bundle. getsymbolicname () ). append ( "\n" ) ; 4 } Ukázka 6.3: Získání seznamu nainstalovaných bundl 6.2.2 display.cuzk.map Tento bundle uº se zabývá ist geoinformatickým tématem, a to zobrazováním katastrální mapy pomocí mapové sluºby poskytované ƒúzk v rámci Nahlíºení do katastru. Aby byly schopnosti tohoto bundlu dostupné uºivateli, je v aktivátoru zaregistrovaná poloºka do menu objekt typu MapDisplayMenuAction implementující rozhraní MenuAction. P i provád ní akce vyvolané uºivatelem se prohledá registr sluºeb pro objekt schopný vykreslit rastrovou mapu a pokud je nalezen, ukáºe se uºivatelské rozhraní vykreslující mapu a poskytující komponenty pro nastavení sou adnic st edu oblasti a m ítka. Neº je v²ak gracké rozhraní zobrazeno, je t eba mu p edat p íslu²ná data v tomto p ípad objekt typu WMSUrl. Tento postup je ilustrován v ukázce 6.4. V ní je také vid t pouºívání ltr ve vyhledávání sluºeb. Aby byla nalezena sluºba vyhovující danému ltru (type=map), musí být zaregistrovaná s p íslu²nými vlastnostmi jak ukazuje 6.5. O tuto registraci se v²ak starají jiné bundly, ty poskytující UI k zobrazování mapy. URL adresa pouºívaná pro získání mapy byla p evzata z [2] a jenom mírn upravena pro specické vyuºití v tomto bundlu. Její konkrétní verze s aktuálními sou adnicemi se vytvá í v implementované metod WMSUrl.buildUrl, a to jmenovit ve t íd CUZKWMSUrl. 47

KAPITOLA 6. BUNDLY 1 // z i s k a n i r e f e r e n c i na r e g i s t r o v a n e s l u z b y 2 ServiceReference [ ] r e f e r e n c e s = bundlecontext. getservicereferences ( 3 DisplayCanvas. class. getname (), 4 " ( type=" + DisplayCanvas.TYPE.MAP. tostring () + " ) " ) ; 5 // pokud neni p o l e r e f e r e n c e s prazdne, 6 // j e mozne z i s k a t k o n k r e t n i o b j e k t : 7 DisplayCanvas canvas = ( DisplayCanvas ) context. getservice ( r e f e r e n c e s [ 0 ] ) ; 8 // n a s t a v i t mu data 9 canvas. setdata (new CUZKWMSUrl() ) ; 10 // a z o b r a z i t UI 11 canvas. display () ; Ukázka 6.4: Hledání v registru sluºeb 1 Hashtable<String, String> p r o p e r t i e s = new Hashtable<String, String >() ; 2 p r o p e r t i e s. put ( " type ", DisplayCanvas.TYPE.MAP. tostring () ) ; 3 bundlecontext. r e g i s t e r S e r v i c e ( DisplayCanvas. class. getname (), 4 new MapDisplayCanvasForm ( bundlecontext ), 5 p r o p e r t i e s ) ; Ukázka 6.5: Registrace sluºby s vlastnostmi 6.2.3 display.points Bundle display.points je velice podobný tomu p edchozímu. Samoz ejm, jak napovídá název, místo mapy zobrazuje body, ale jiná zásadní odli²nost je ve zp sobu, jakým získává data k vykreslení. Zatímco bundle display.cuzk.map pracuje s webovou mapovou sluºbou, display.points data získává ze souboru a pro tuto akci musí nejprve nalézt zaregistrovaný parser sou adnic. Následn data v podob bod p edá objektu typu DisplayCanvas a ten zobrazí gracké UI. V bundlu se vyskytují pouze dv t ídy, a to aktivátor a PointsDisplayMenuAction implementující MenuAction. Ke správné práci je v²ak zapot ebí do aplikace doinstalovat n jaký bundle registrující implementovaný parser sou adnic CoordinatesParser. 6.2.3.1 parser.coordinats.csv Jak vyplývá z p edcházejících odstavc, tento bundle p idává do registru sluºeb objekt schopný parserovat CSV soubory obsahující seznamy sou adnic. Parsery je vhodné registrovat zp sobem ukázaným v 6.6, aby byla moºná ltrace sluºeb podle formátu vstupního souboru. Samotná funkcionalita umoº ující parserování je implementovaná velice jednodu²e a jist nejde o bezchybný CSV parser. 48

6.3. BUNDLY POSKYTUJÍCÍ UšIVATELSKÉ ROZHRANÍ 1 Hashtable<String, String> p r o p e r t i e s = new Hashtable<String, String >() ; 2 p r o p e r t i e s. put ( " extension ", " csv " ) ; 3 bundlecontext. r e g i s t e r S e r v i c e ( CoordinatesParser. class. getname (), 4 new CSVCoordinateParser (), 5 p r o p e r t i e s ) ; Ukázka 6.6: Registrace CSV parseru 6.3 Bundly poskytující uºivatelské rozhraní Vzhledem k faktu, ºe bylo zamý²leno p ipravit p íklady OSGi bundl pro t i r zné typy aplikací vyuºívajících r zné gracké knihovny, musela být funkcionalita poskytující UI vytvo ena pro kaºdou aplikaci zvlá² a vznikly tedy t i sady bundl. Mimo tyto sady existují je²t bundly popisované v následujících dvou sekcích. Následn jsou probrány postupn bundly pro Eclipse RCP, NetBeans RCP a swingovou aplikaci. 6.3.1 ui.manager.bundles Bundle ui.manager.bundles poskytuje jednoduchého grackého správce nainstalovaných bundl. Jak je vid t na obrázku 6.1, dialogové okno obsahuje seznam nainstalovaných bundl a sadu tla ítek pro zacházení s t mito moduly a také pro instalaci nových, pomocí dialogu pro výb r souboru. Obrázek 6.1: Plugin manaºer 49

KAPITOLA 6. BUNDLY O manipulaci s bundly se stará samotné okno reprezentující manaºer objekt typu PluginsWindow. Krom kódu obsluhující události vyvolané uºivatelem tato t ída neobsahuje tém nic. Tyto události mohou být ty typ podle stisknutého tla ítka a jedná se o volání metod na vybraných bundlech: Bundle.start, Bundle.stop, Bundle.uninstall nebo BundleContext.installBundle. Aktivátor bundlu je velice jednoduchý a jediné, co se provádí v metod start, je registrace poloºky do menu. Dále bundle obsahuje jedno pomocné rozhraní BundleHandler pro manipulaci s moduly a t ídu Const obsahující pouze p evod celo íselné hodnoty ur ující stav bundlu (aktivní, nainstalovaný,...) na et zcovou hodnotu uloºený v datové struktu e HashMap. Jelikoº se v bundlu vyuºívá gracké knihovny Swing, která není umíst na v balí ku java ale javax.swing, musí soubor MANIFEST.MF obsahovat hlavi ku importující tento balí ek: Import-Package: javax.swing. Stejn tak je tomu i u ostatních bundl pouºívajících tuto knihovnu. 6.3.2 ui.display.canvases Tento bundle obsahuje dv t ídy pod d né z JPanel, které p episují metodu paint, v níº vykreslují zadaná data. T mito t ídami jsou: MapDisplayCanvas obsahující metodu setimage(image) a PointsDisplayCanvas s metodou setpoints(list<point3d>). 6.3.3 Eclipse RCP Jak bylo zmín no na za átku této kapitoly, i bundly pracující s Eclipse RCP byly vyvíjeny v prost edí NetBeans jako oby ejné Java projekty. Aby tomu tak mohlo být, bylo pot eba vytvo it knihovnu Eclipse platformy pro importování do projekt. Podle nastavení knihoven vyuºívajících Eclipse platformu v Eclipse IDE byla v NetBeans vytvo ena knihovna EclipseRCP obsahující následující JAR archivy obsaºené v adresá i nainstalovaného Eclipse IDE ve sloºce plugins: org.eclipse.core.commands, org.eclipse.core.contenttype, org.eclipse.core.jobs, org.eclipse.core.runtime, org.eclipse.core.runtime.compatibility.registry, org.eclipse.equinox.app, 50

6.3. BUNDLY POSKYTUJÍCÍ UšIVATELSKÉ ROZHRANÍ org.eclipse.equinox.common, org.eclipse.equinox.preferences, org.eclipse.equinox.registry, org.eclipse.jface, org.eclipse.osgi, org.eclipse.swt, org.eclipse.swt.gtk.linux.x86_64, org.eclipse.ui, org.eclipse.ui.workbench. Oproti oby ejným projekt m musí Eclipse Platform projekty obsahovat je²t soubor plugin.xml, pokud je zapot ebí registrovat n která roz²í ení. 6.3.3.1 ui.eclipse.display Díky tomuto pluginu je moºné zobrazovat mapu a vykreslovat body p i vyvolání uºivatelských akcí zpracovávaných bundly display.cuzk.map a display.points. Práv tento bundle poskytuje uºivatelské rozhraní k zobrazování p íslu²ných dat. V metod Activator.start se zaregistrují objekty do seznamu sluºeb, aby k nim mohly ostatní bundly p istupovat, vyuºívajíce známé rozhraní DisplayCanvas, které je t ídami samoz ejm implementováno (ukázka 6.7). 1 Hashtable<String, String> p r o p e r t i e s 1 = new Hashtable<String, String >() ; 2 p r o p e r t i e s 1. put ( " type ", DisplayCanvas.TYPE.POINTS. tostring () ) ; 3 bundlecontext. r e g i s t e r S e r v i c e ( DisplayCanvas. class. getname (), 4 new PointsDisplayCanvasEditorInput (), 5 p r o p e r t i e s 1 ) ; 6 7 Hashtable<String, String> p r o p e r t i e s 2 = new Hashtable<String, String >() ; 8 p r o p e r t i e s 2. put ( " type ", DisplayCanvas.TYPE.MAP. tostring () ) ; 9 bundlecontext. r e g i s t e r S e r v i c e ( DisplayCanvas. class. getname (), 10 new MapDisplayCanvasEditorInput (), 11 p r o p e r t i e s 2 ) ; Ukázka 6.7: Registrace objekt pro zobrazování p íslu²ných dat Jak je z ukázky vid t, registrovanými objekty jsou takzvané editor inputy. Jedná se o t ídy implementující, mimo jiné, rozhraní IEditorInput, které se pouºívají p i otvírání editor v Eclipse platform. 51

KAPITOLA 6. BUNDLY ƒást bundlu týkající se vykreslování bod se skládá ze dvou t íd: PointsDisplayCanvasEditorInput a PointsDisplayCanvasEditor. T ída PointsDisplayCanvasEditorInput tedy implementuje rozhraní IEditorInput a DisplayCanvas. V metodách denovaných rozhraním IEditorInput není v podstat ºádný kód a v t ch z DisplayCanvas je ho také málo. Implementace metody DisplayCanvas.setData zajistí typovou kontrolu vstupních dat a pokud je v po ádku, data uloºí. Jinak je vyhozena výjimka typu IllegalArgumentException. V metod DisplayCanvas.display se provádí vlastní zobrazení editoru jediným ádkem, jak je vid t na ukázce 6.8. 1 PlatformUI. getworkbench () 2. getactiveworkbenchwindow () 3. getactivepage () 4. openeditor ( this, PointsDisplayCanvasEditor. ID) ; Ukázka 6.8: Otev ení editoru zobrazující body Editor je t ída roz²i ující abstraktní t ídu EditorPart a d leºitou ástí je její metoda createpartcontrol(composite), která do vstupní komponenty m ºe p idat jakékoliv dal²í gracké prvky. Jelikoº má tento editor vykreslovat na obrazovku body, bude jeho jediná gracká komponenta jiº zmín ný PointsDisplayCanvas roz²i ující t ídu JPanel z knihovny Swing. Jelikoº Eclipse platforma vyuºívá zcela jinou grackou knihovnu SWT není moºné objekt typu JPanel p ímo p idat do komponenty typu Composite. Aby v²ak bylo moºné tyto gracké prvky pouºívat, existuje m stek p evád jící SWT komponenty na AWT a ty uº se swingovými komponentami dokáºí pracovat. Pouºití tohoto m stku ukazuje 6.9. 1 public void createpartcontrol ( Composite parent ) { 2 Composite awtcomponent = new Composite ( parent, SWT.EMBEDDED) ; 3 Frame frame = SWT_AWT. new_frame( awtcomponent ) ; 4 frame. add (new JPanel () ) ; 5 } Ukázka 6.9: P evod SWT komponenty na AWT Dal²í ástí bundlu jsou t ídy obstarávající vykreslování katastrální mapy získané pomocí WMS. Krom editoru a editor inputu, které byly pot eba i pro vykreslování bod, je pro správnou funkci pot eba je²t pohled (view) a perspektiva. Pohled je vyuºitý pro zobrazení a správu komponent umoº ujících uºivateli nastavit oblast zobrazovanou na map a perspektiva ur uje rozloºení pohledu a editoru v hlavním okn aplikace. Perspektiva je t ída implementující rozhraní IPerspectiveFactory obsahující jedinou metodu createinitiallayout. V konkrétním p ípad t ídy MapDisplayPerspectiveFactory je implementace zmín né metody velice jednoduchá ukázka 6.10. Pohled MapDisplayCanvasSettingsView, potomek t ídy ViewPart, obsahuje komponenty pro uºivatelské nastavení stahované mapy, které jsou vytvá eny v metod 52

6.3. BUNDLY POSKYTUJÍCÍ UšIVATELSKÉ ROZHRANÍ 1 public void c r e a t e I n i t i a l L a y o u t ( IPageLayout layout ) { 2 layout. addview ( MapDisplayCanvasSettingsView. ID, 3 IPageLayout.LEFT, 4 0.33 f, 5 layout. geteditorarea () ) ; 6 } Ukázka 6.10: Tvorba perspektivy createpartcontrol. Pro zachování ukázkového rázu aplikace bylo uºivateli umoºn no jen velmi strohé nastavení výsledné mapy bez interaktivity zobrazení. V t²ina dat pot ebných k sestavení URL adresy pro WMS byla zvolena napevno a uºivatel je schopen nastavit pouze sou adnice st edu oblasti zobrazené na map v sou adnicích JTSK a m ítko mapy. P i vytvá ení URL se bere v úvahu také velikost vykreslovací komponenty v souvislosti s velikostí obrázku vráceného mapovou sluºbou. Toto platí i pro dal²í dva bundly poskytující stejnou funkcionalitu, vyuºívajíce jiných grackých komponent, a to ui.netbeans.display a ui.swing.display. P i vývoji grackých prvk pohledu s nastavením bylo vyuºito návrhá e WindowBuilder, který je jako plugin poskytován do Eclipse IDE. S programováním komponent Eclipse platformy je tento návrhá velmi dob e integrován. Editor zobrazující mapu a jeho editor input je velice podobný tomu vykreslujícímu body. Za zmínku v²ak stojí zm na v metod DisplayCanvas.display, kde se musí krom editoru zobrazit také poºadovaná perspektiva s pohledem (ukázka 6.11). 1 PlatformUI. getworkbench () 2. showperspective ( 3 MapDisplayPerspectiveFactory. ID, 4 PlatformUI. getworkbench (). getactiveworkbenchwindow () ) ; 5 PlatformUI. getworkbench () 6. getactiveworkbenchwindow () 7. getactivepage () 8. openeditor ( this, MapDisplayCanvasEditor. ID) ; Ukázka 6.11: Otev ení editoru zobrazujícího mapu a perspektivy s pohledem pro nastavení Výsledná perspektiva s otev eným editorem zobrazujícím mapu je vyobrazena na ilustraci 6.2. 6.3.3.2 ui.eclipse.dialogs Bundle poskytující dialogová okna závislá na pouºité vývojové platform obsahuje pouze dv t ídy. První z nich je klasický Activator a tou druhou je t ída EclipseFileDialog implementující rozhraní OpenFileDialog. V aktivátoru je provedena jediná v c, a to vloºení instance t ídy EclipseFileDialog do registru sluºeb pod jméno implementovaného rozhraní. 53

KAPITOLA 6. BUNDLY Obrázek 6.2: Zobrazení katastrální mapy v Eclipse RCP aplikaci K vlastnímu získání souboru k otev ení je vyuºito standardního dialogového okna z knihovny SWT FileDialog. P i pouºívání Eclipse platformy je vhodné jako Shell vstupující do konstruktoru dialogu zvolit Shell hlavního okna, jenº se dá získat následujícím zp sobem: PlatformUI.getWorkbench().getActiveWorkbenchWindow().getShell(). 6.3.4 NetBeans RCP Protoºe NetBeans platforma nepodporuje nativn OSGi bundly, bylo vyuºito nástroj pro vývoj NetBeans modul. Pro projekty byla vytvo ena obalová struktura module suite a celý vývoj musel být uzp soben faktu, ºe NetBeans aplikace s bundly neum jí pracovat tak jako aplikace mající za nativní runtime prost edí OSGi framework. 54

6.3. BUNDLY POSKYTUJÍCÍ UšIVATELSKÉ ROZHRANÍ 6.3.4.1 ui.netbeans.display Stejn tak jako alternativa tohoto bundlu pro Eclipse platformu, i zde jsou dv t ídy implementující rozhraní DisplayCanvas, pod jehoº jménem jsou také jejich instance zaregistrované do seznamu sluºeb. Krom t chto t íd a aktivátoru, který se o zmín nou registraci stará, bundle obsahuje je²t t i t ídy reprezentující okna pro zobrazování dat a nastavení. T ídy týkající se zobrazování katastrální mapy jsou MapDisplayCanvasSettingsTopComponent umoº ující uºivateli nastavení oblasti zobrazené na map, MapDisplayCanvasTopComponent obsahující komponentu MapDisplayCanvas z bundlu ui.display.canvases, vykreslující vlastní mapu a MapDisplayCanvas implementující rozhraní DisplayCanvas, která zobrazuje dv zmín né top komponenty. Vzhled aplikace p i zobrazení katastrální mapy je k vid ní na obrázku 6.3. Obrázek 6.3: Zobrazení katastrální mapy v NetBeans RCP aplikaci Dal²í ást bundlu se týká zobrazování bod a jediným znatelným rozdílem ve struktu e t íd je absence komponenty s nastavením. Implementací rozhraní DisplayCanvas je t ída PointsDisplayCanvas a t ída PointsDisplayCanvasTopComponent poskytuje uºivatelské rozhraní s jedinou komponentou PointsDisplayCanvas z bundlu ui.display.cavases. Jelikoº tento bundle vyuºívá n kolik t íd z jiných balí k neº java, musí jeho manifest obsahovat hlavi ku Import-Package, v následující podob : 55

KAPITOLA 6. BUNDLY Import-Package: org.osgi.framework, org.openide.windows, org.openide.util, org.openide.awt. 6.3.5 Swing Vývoj bundl bez vyuºití jakékoliv rich client platformy, pouze za pouºití gracké knihovny Swing, byl velmi jednoduchý, protoºe jediným rozdílem oproti zcela oby ejnému bundlu bez uºivatelského rozhraní byla nutnost importovat pot ebné balí ky pomocí hlavi ky Import-Package, nap.: Import-Package: org.osgi.framework,javax.swing. Obrázek 6.4: Zobrazení katastrální mapy ve swingové aplikaci P i pouºití t íd vno ených do dal²ích balí k v javax.swing je t eba konkrétní specikace kaºdého balí ku zvlá² : Import-Package: org.osgi.framework, 56