nyílt fejlesztőrendszerek plugin fejlesztés

Budapest University of Technology and Economics

Fault-tolerant Systems Research Group

Nyílt FejlesztőrendszerekPlugin fejlesztés

2Budapest University of Technology and Economics


Extension point-ok

Safe platform rule− „As the provider of an extension point, you

must protect yourself against misbehavior on the part of extenders”

A felkínált kiegészítési pontnak biztonságosnak kell lenni, még a kiegészítés hibája esetén is!

Invitation rule− „Whenever possible, let others contribute to

your contributions”



Extension point-ok

Fair play rule− „All clients play by the same rules, even me.”− Ne legyen saját „hátsó bejárat”, rejtett

interfészExplicit Extension Rule

− „Declare explicitly where a platform can be extended”

− A deklaráció a plugin.xml-benDiversity Rule

− „Extension points accept multiple extensions”



Extension point-ok

Hogyan kérdezhetjük le a ponthoz tartozó kiegészítéseket?− Platform.getExtensionRegistry()− IExtensionRegistry.getExtensionPoint(String)− IExtension[] IExtensionPoint.getExtensions()− IExtension.getConfigurationElements()

● Az adott elem attribútumait, gyerekeit tartalmazza● Validáció kérhető



Extension point-ok

Hogyan példányosítjuk a megadott osztályt?− Csak egy osztálynév van− A mi classloader-ünk nem találhatja meg,

mert nincs a függő plugin-ok listáján− Nem is biztos, hogy kívülről látszik az osztály− Megoldás: kérjük meg az extension plug-in

saját classloader-ét, hogy végezze el a piszkos munkát!

● IConfigurationElement.createExecutableExtension(String)



Extension-ök értesítése/hívása

Hogyan értesítjük az extension-t?− Adott hívási felület (interface)− Fel kell készülni a hibákra, exception-ökre

● Kivételkezelés!● Minden extension hívást külön try-catch blokkban

Fault containment region…

− Good fences rule: „When passing control outside your code, protectyourself.”

− Intézményesített gyanakvás: ISafeRunnable



Extension-ök értesítése/hívása

ISafeRunnable− public void run() – ebbe tegyük a futtatandó

kódot− public void handleException(Throwable)

● Kezeli a kivételeket, amik futtatás közben keletkeztek

● Például kidobhatjuk az extension-t, ha bajt okozott



Példa: ISafeRunnable

for (Iterator all=getListeners().iterator();all.hasNext())

{

IMyExstension ext = (IMyExtension)all.next();

ISafeRunnable runnable = new ISAfeRunnable() {

public void handleException(Throwable exception){

all.remove();

}

public void run() throws Exception {

ext.execute(); //hívom az extensiont

}

};

Platform.run(runnable);

}





{




all.remove();

}



}

};


}

Végigmegyünk az extension-ökön





{




all.remove();

}



}

};


}

Kivesszük a következőt





{




all.remove();

}



}

};


}

Csinálunk egy új burkoló-osztályt





{




all.remove();

}



}

};


}

Aki hibázik, azt eldobjuk





{




all.remove();

}



}

};


}

Meghívjuk az extension egyik metódusát





{




all.remove();

}



}

};


}

Végrehajtjuk a runnable-t.



Csomagolás, publikálás

Ha készen áll a plugin-ünk a felhasználásra− Be kell csomagolni− Hangolni kell a plugin.xml opcióit

Telepítési cél− Saját gépünk− Más gépek− Automatikus telepítés/frissítés




Könyvtárak – library− A csomagolás első lépése− Osztályainkat jar fájlokba csomagtatjuk

● Lehet bináris vagy forrás csomag● Megmondhatjuk, mely osztályok látszódhatnak

kívülről

− A kész libeket és egyéb fájlokat csomagolhatjuk össze az exporthoz

● Lehet bináris és forrás bundle




Finomhangolás− Nem használt függőségek kiirtása

● Automatikus ellenőrző eszközökkel− Plugin neve, készítő, …− Verziószám beállítása

Export− File -> Export -> Deployable plug-ins and

fragments● Az eredmény egy könyvtár, ami tartalmazza a

plugint.



Feature

Egy témához kapcsolódó plug-inek gyűjteménye

Könnyebb menedzselhetőség érdekében jött létre

Az automatikus letöltés és telepítés atomi egysége



Feature

Kiegészítő információk− License aggreement− License rule „always supply a license with

every contribution”− Upgrade site-ok listája− Feature saját verziója− Szükséges pluginok verziója



Update site

Automatikusan létrehozott weblapFeature-ök elhelyezésére

− Publikálás− Letöltés− Upgrade

Lista az elérhető feature-ökről és verziókról

Megkönnyíti a szoftver elosztást



Eddig

Egyszerű plugin létrehozásaKiterjesztések létrehozásaKiterjesztési pontok létrehozásaPlugin csomagolásFeature létrehozásUpdate site



Plugin fejlesztés teszteléssel



JUnit

Regressziós teszt keretrendszerErich Gamma és Kent Beck írtaUnit tesztelésre használatos Java-banNyílt forráskódúIBM CPL licensz alatt elérhető



JUnit

Web: http://junit.org/index.htmAz Eclipse tartalmazza a JUnit-ot

− GUI-t is kínál a tesztek futtatásához

Eclipse-n kívül is futtathatóak a tesztek



Eclipse - JUnit

A JUnit beállítása a Preferences ablakban lehetséges

Általában jók az alapbeállítások

Szűrőket lehet megadni, hogy mely csomagok és osztályok jelenjenek meg a stack trace-ben



TestCase - teszteset

Több tesztet is futtathatA TestCase osztályból származikDefiniálja, hogy mely tagváltozók

tartalmazzák a teszt állapotát az osztályon belül

Inicializálás a setUp metódussalTakarítás a tearDown metódussal



TestCase készítése

Csináljunk egy új osztályt a project-ben

Adjuk hozzá a junit.jar-t a függőségekhez



TestCase létrehozása

Kiválasztjuk a csomagot, ahova a tesztet rakni szeretnénk

A new menüből válasszuk a JUnit Test Case-t.

Elnevezzük, stb.Egy megfelelő osztály létrejön



Példa: TestCase

package com.espirity.course.testing;import junit.framework.TestCase;public class FirstTestCase extends TestCase {public FirstTestCase(String arg0) {super(arg0);}public static void main(String[] args) {}protected void setUp() throws Exception {super.setUp();}protected void tearDown() throws Exception {super.tearDown();}}




Minden „test”-tel kezdődő metódus tesztként lesz kezelve az osztályban− Sok teszt metódusunk lehet

Minden teszt metódus többféle „assert” metódust használhat, hogy a tesztelés alatt álló osztályok állapotát vizsgálja− Az assert metódusok öröklöttek




Assert− assertEqual(x,y)− assertFalse(boolean)− assertTrue(boolean)− assertNull(Object)− assertNotNull(Object)− asserSame(Object,Object)− assertNotSame(Object,Object)



Példa: TestCasepackage testing;import junit.framework.TestCase;public class FirstTestCase extends TestCase {public FirstTestCase(String arg0) {super(arg0);}public static void main(String[] args) {}protected void setUp() throws Exception {super.setUp();}protected void tearDown() throws Exception {super.tearDown();}public void testCompareSucceed() {assertEquals(0, 0); //this assertion will succeed}public void testCompareFail() {assertEquals(0, 1); //this assertion will fail}}



TestCase futtatása

Válasszuk ki az osztályt

Run -> Run as -> JUnit Test

Lefutnak a tesztek

Az eredmény a JUnit view-ban jelenik meg.



JUnit view

Információk− Piros/zöld a teszt eredménye hiba/ok− Látható a meghiúsult tesztek neve− Látható a hiba trace− Látható a lefutott tesztek száma− Látható a hibák száma



TestSuite

Több TestCase vagy Suite futtatásaA TestSuite osztályból örököltetjükLétrehozás varázslóval…

− File->New->Other…->Java->JUnit− A varázslóban válasszuk a JUnit Test Suite

opciót− Megadhatjuk a résztevő Case-eket



Példa: TestSuite

package com.espirity.course.testing;import junit.framework.Test;public class AllInclusiveTestSuite {public static Test suite() {TestSuite suite =new TestSuite("Test for com.espirity.course.testing");

//$JUnit-BEGIN$suite.addTestSuite(FirstTestCase.class));suite.addTestSuite(SecondTestCase.class));//$JUnit-END$return suite;}}



TestSuite futtatás

Hasonló a TestCase-éhezMinden megadott TestCase lefutA JUnit ablak tartalmazza az

eredményeket

Fontos: TestSuite is adható TestSuite-hoz!



PDE JUnit

JUnit támogatás plug-in fejlesztéshezA sima JUnit nem használható

− Nem Workbench-ben fut− Az Eclipse plug-inok nem leérhetőek

PDE JUnit− Külön futtatási mód



Plugin futtatás

Alap Eclipse, ezen dolgozunk



Plugin futtatás

Projectek a workbench-ben



Plugin futtatás

Ha plugint futtatunk egyúj Eclipse példány indul



Plugin futtatás

Betöltődik a plugin-unk



Plugin futtatás

Külön workspace látszik



Plugin teszt futtatás

Teszt projekt a workspace-ben



Plugin teszt futtatás

A teszt is betöltődik, valamint a teszt futtató



PDE JUnit működés

Írunk egy tesztet (ugyanúgy, mint alapesetben)

Futtatjuk JUnit Plug-in Test-kéntEgy Eclipse ablak nyílik, majd a tesztek

lefutása után bezáródikA teszteredményt a szokásos ablakban

találhatjuk meg



PDE JUnit működés

Hol legyenek a tesztek?− Lehet a tesztelendő plug-inban is− De!

● A JUnit függőségeket be kell építeni● Keveredik a kód és a teszt

− Tegyük külön plug-inba, ami könnyen leválasztható

● Ez függ az eredeti plug-in-től



Mit teszteljünk?

Nyilván csak a meghajtható részek (API) tesztelhető

Nincs lehetőség közvetlen GUI tesztre− Rational Robot

Amit tesztelni szeretnénk, látható kell legyen

Erősen függ a konkrét plug-intól



Gyakori kiterjesztések



View

Általános információ-megjelenítő elemExtension point:

− org.eclipse.ui.views− If: IViewPart

Sokféle lehetőség van információ megjelenítésére− Tartalmazhat SWT és JFace elemeket is



Példa: View

public class View extends ViewPart { public static final String ID = "raktarAppFrontend.view";

private TreeViewer viewer; public void createPartControl(Composite parent) {

//View controls initialization}/** * Passing the focus request to the viewer's control. */public void setFocus() {viewer.getControl().setFocus();

}



View

setFocus metódus− Hova kerüljön a fókusz?− Nekünk kell megmondani…− Program to API contract rule: „Check and

program to the Eclipse API contract.”− Ezt a metódust nekünk nem szabad hívni!− Helyette: IWorkbenchPage.showView(String)− És: IWorkbenchPage.activate(IViewPart)



View

Általános információ-megjelenítő elemExtension point:

− org.eclipse.ui.views− If: IViewPart

Sokféle lehetőség van információ megjelenítésére− Tartalmazhat SWT és JFace elemeket is



Menü elemek

Pop-up menü: ActionSet-ek (már volt)Context Menü

− Jobbgombra előugró menü egy adott elemen− Invitation rule-> általában mindegyik context

menü fogad új elemeket− Elemek: Action-ök, separator-ok− Két speciális elem, amik közé mások menü

elemei kerülhetnek (MB_ADDITIONS)− Hozzáadás: org.eclipse.ui.popupMenus

● A View megadásával



Perspektívák

Layot-ot definiál a megjelenítendő view-k és editorok számára

Pl. Java/Debug/Resource perspektívákPerspektíva kiegészítése

− Megadható hol jelenjen meg a view, ha megnyitják

− Kezdetben látható legyen a view?

RCP alkalmazásoknál teljesen új perspektívát készítünk! (programozottan)



Help

Minden plugin tartalmazhat help-etAlapelem: TOC – Table of contents

− Fa− Más toc-okat és topic-okat tartalmaz

Topic− Egy html fájl

Extension point: org.eclipse.help.tocLehet különálló plugin (nem keveredik a

kóddal)



Help készítése

A fő toc: toc.xml-ben (konvenció)

<toc label=„PDE Guide”>

<topic label=„Introduction” href=„intro/index.html”/>

…

</toc>



Help

Topic elemek− Van címkéjük− Van egy fájl hivatkozás a tartalmukra− Ha a címkét kiválasztjuk, betöltődik a

megadott fájl− A HTML minden elemet tartalmazhat, amit

általában (képek, linkek, …)



Help – plugin.xml

<requires>

…

<import plugin=„org.eclipse.help”/>

</requires>

<extension point=„org.eclipse.help.toc”>

<toc file=„toc.xml” primary=„true”/>

</extension>



Integrált Help

Topic hozzáadása létező help-hez Pl. határtalan tudásunkkal gyarapítni szeretnénk

a beépített PDE súgót Anchorok helyezhetőek el a toc-ban (invitation

rule) Toc link_to attribútum -> útvonal a toc

gyökeréhez (az anchorhoz) Példa:<toc label=„Uj elem”

link_to=„../org.eclipse.jdt.doc.user/topics_Concepts.xml#c_javabuilder”>



Context sensitive help

„F1” szindrómaHozzárendelés:

− WorkbenchHelp.setHelp(Control,String)

Help context extension:− Egy xml fájl, ami leírja a context-eket (mely

topicok jelennek meg, …) + egy description (általános szöveg)

− Ezt az xml-t mint org.eclipse.help.context extension-t kell bejegyezni



Internationalization

A plug-inok nemzetközivé tétele, többnyelvűsítése

Első lépésben eltávolítjuk a string konstansokat a kódból és egyéb fájlokból, hogy könnyen cserélhető legyen a felület szövege



I18N – plugin.xml

A plugin.xml egyes szövegei csak a rendszer számára láthatóak (extension id, …) ezeket nem kell lefordítani

Másokat viszont a felhasználó is lát (action label) – ezeket ki kell szedni, hogy könnyen le lehessen fordítani− plugin.properties – név érték párok− %név – az adott helyre behelyettesíti a talált értéket

feature.xml-nél hasonló módszer (feature.properties)



I18N – forráskód

A Java forráskód egy része felhasználó számára látható szöveget tartalmaz (gombfelirat, üzenetek…) – ezeket ki kellene szedni…

Más stringek viszont fontos rendszer-konstansokat tartalmaznak (id, …) – ezekenek maradni kell

Megoldás: megjelöljük a maradókat: //$NON-NLS-1$



I18N – forráskód

Előkészületek:− Resource bundle létrehozása a plug-in-hoz

(akrá több is)− Minden bundle-be rakjunk egy properties fájlt

(pl. messages.properties), és egy helper osztályt, mely ezt betölti

− A kulcsok legyenek kvalifikáltak, hogy ne legyen ütközés (pl. Osztaly.elem.attributum)



Eclipse támogatás

Source -> Externalize strings− Megkeresi a stringeket, létrehozza a bundle-t és a

beolvasó segédosztályt.− Mindent elrendez nekünk



Probléma - publikálás

Mit tegyünk a plugin publikálásakor?Várjuk meg az összes fordítást? –

időveszteségAdjunk ki új verziót minden fordításkor? –

bonyolultMegoldás: fragment-ek

− Külön elemek, melyek a plugin egy részét tartalmazzák – nyelv vagy platform specifikus elemekhez találták ki



Accessibility

A plugin legyen elérhető hátrányos helyzetűek számára is− Minden funkció legyen elérhető billentyűzetről− Az elemekhez rendeljünk cimkéket, hogy a felolvasó

programok számára legyen elégéséges információ− A színeket csak mint kiterjesztést használjuk− Tegyük lehetővé erős kontrasztos üzemmód

használatát− A hangjelzések és kép legyen kiváltható



A plugin megnyitása más programozók számára

API definiálása− Meg kell határrozni, mely interfészek, osztályok

látszanak, melyeket kell másoknak használni− Csak a szükségeseket exportáljuk− Az exportán megadhatunk egy prefixet is az

osztálynevekre -> teljesítmény!



Belső és nyilvános csomagok

Explicit API rule: „Separate the API from internals”

− Lehetőleg világosan el legyen választva a nyilvános API és a belső osztályok (pl. külön csomag)

Stability rule: „Once you invite others to contribute, don’t change the rules”

− Lehetőleg tartsuk stabilan az API-t

Defensive API rule: „Reveal only the API in which you have confidence, but be prepared to reveal more API as clients ask for it.”

− Csak a stabil részeket mutassuk meg



Core és UI

A nagy komponensek általában külön plug-inbe helyezik a belső működést és az UI-t

Ez praktikus, és kikényszeríti a kettő közötti interfész definiálását− Könnyen cserélhető, kiegészíthető GUI− Külön-külön fejleszthető elemek



Extension point

A hivatalos kiegészítési mechanizmus alapeleme

Fontos, hogy definiáljunk hozzá megfelelő sémát!− Ez adja meg a használható elemeket

nyílt fejlesztőrendszerek plugin fejlesztés

Documents