A logikai modellek teljeskörű támogatásához a lerakatszolgáltatók az alábbi műveleteket tudják elvégezni:
ResourceMapping
osztályhoz
adaptálásra kerülő elemekhez. ISynchronizationScope
és
egy támogató alkalmazás programozási felület segítségével biztosítják,
hogy az erőforrás-kiosztásokon végzett műveletek tartalmazzák az összes
megfelelő modellelemet és erőforrást. IMergeContext
felület, illetve a
támogató alkalmazás programozási felület segítségével megjelenítés nélküli
összefésülésben vegyenek részt. teamContentProviders
segítségével
összefésülési előképekben szerepeljenek. A modelltartalom, az
összefésülési kontextus, illetve az Összehasonlító keretrendszer közt
fennálló viszony kezelésének megkönnyítésére egy
ModelSynchronizeParticipant
osztályt biztosítanak. IFileHistoryProvider
alkalmazás programozási felület segítségével hozzáférést biztosítanak a
munkaterület fájlok történetéhez. ProjectSetCapability
segítségével a
munkaterület projektekhez csatolják. SynchronizationStateTester
alkalmazás programozási felülethez használható munkaterület
Subscriber
elemeket biztosítanak a logikai modellelemek
kiemelésének támogatásához. Az alábbi szakaszok részletesen tárgyalják az előzőekben ismertetett pontok mindegyikét. Számos pont működésének bemutatására az org.eclipse.team.examples.filesystem bedolgozó tartalmaz példákat. A projektet kiiktatható a CVS lerakatból, és hivatkozásként használható az ismertető olvasása közben. Jogkizárási nyilatkozat: A példabedolgozókban lévő forráskód változhat. A példában használtnak megfelelő másolat megszerzéséhez a 3.2 változathoz tartozó címke (általában R3_2) vagy a 2006. június 28. dátumcímke segítségével ellenőrizheti a projektet.
Az erőforrás-leképező API az alábbi osztályokból áll:
Object getModelObject()
: Az a modellobjektum, amelyből
a leképezés származik (vagy adaptálásra került). ResourceTraversal[] getTraversals(ResourceMappingContext,
IProgressMonitor)
: Az erőforrás bejárási út, amely magába foglalja
a modellobjektumot alkotó erőforrásokat. ResourceTraversal
metódusok erőforrások egy halmazát
tartalmazzák, illetve egy mélységparamétert, amely azt jelöli, hogy a
bejárási út erőforrásai milyen mélységben tartoznak az eredeti
modellobjektumhoz. Az erőforrás bejárási utakat az ügyfelek számára az
erőforrás leképezések biztosítják. Céljuk, hogy a modellek tartalmát olyan
módon írják le, hogy az ügyfél (pl. egy lerakatszolgáltató) műveleteit a
lehető leghatékonyabb módon végezhesse. A fontosabb metódusok az alábbiak:
getResources()
getDepth()
ResourceMappingContext
és
RemoteResourceMappingContext
használata valamivel bonyolultabb, ezért ezeket egy
későbbi fejezetben tárgyaljuk. Az erőforrás-leképezések szempontjából a bedolgozók két típusa lehet fontos: Egyrészt azok, amelyek a munkaterületen található erőforrásokból álló, illetve az ott tárolt modelleket biztosítják, másrészt pedig azok, amelyek az erőforrásokon szándékoznak műveleteket végezni. Az előbbi esetet a modell útiterv, míg az utóbbit a következő fejezet tárgyalja.
Az új ResourceMapping
alkalmazás programozási felületek
támogatásához két módosítást kell elvégezni azokon a bedolgozókon,
amelyek az adaptálható kiterjesztési pontokhoz bővítményeket adnak közre:
IResource
helyett a ResourceMapping
osztályra mutasson (azokra a
pontokra vonatkozóan, ahol ez megfelelő). IResource
helyett a ResourceMapping
osztályon működjenek és
betartsák a bejárási utakban megadott mélység-megszorításokat. Ha a művelet több erőforrásra is vonatkozhat, akkor az
IResource
elemhez objektumhozzájárulásokat adó bedolgozók
mostantól azokat a ResourceMapping
osztályhoz adhatják hozzá.
Az alábbi XML kódrészlet egy erőforrás-leképezésekhez adaptálódó
objektumokhoz ad hozzá egy menütevékenységet:
<extension point="org.eclipse.ui.popupMenus"> <objectContribution objectClass="org.eclipse.core.resources.mapping.ResourceMapping" adaptable="true" id="org.eclipse.team.ccvs.ui.ResourceMapperContributions"> <enablement>
<adapt type="org.eclipse.core.resources.mapping.ResourceMapping">
<test
property="org.eclipse.core.resources.projectPersistentProperty"
args="org.eclipse.team.core.repository,org.eclipse.team.cvs.core.cvsnature" />
</adapt>
</enablement>
<action
label="%UpdateAction.label"
definitionId="org.eclipse.team.cvs.ui.update"
class="org.eclipse.team.internal.ccvs.ui.actions.UpdateAction"
tooltip="%UpdateAction.tooltip"
menubarPath="team.main/group2"
id="org.eclipse.team.cvs.ui.update">
</action>
...
</objectContribution>
</extension>
A ResourceMapping
osztályhoz tartozó hozzájárulások az
IResource
elemhez adaptálódó objektumokra is automatikusan
vonatkoznak. Ezt a tranzitív társítást a Munkaterület kezeli. Az
erőforrás-leképezésekhez tartozó hozzájárulások szűrésére a felkészítési
kifejezések segítségével nyílik mód. A termék egy olyan kifejezéssel
bővült, amely lehetővé teszi a projekt állandó tulajdonsága alapján
történő szűrést. Ennek köszönhetően a lerakatszolgáltatók megjeleníthetik
saját menüiket a lerakatukhoz leképzett projekteken.
Az eddigiekben a ResourceMapping
osztályhoz hozzáadott
műveletek egy vagy több ResourceMappings
elemet tartalmazó
kijelölést kapnak. Az erőforrás-leképezések feloldását a műveletek
céljaként megadott erőforrásokra a művelet végzi. Ez a
getTraversals
hívásával, tehát a leképezés bejárási útjának
lekérdezésével lehetséges. A bejárási utak segítségével a bejárási út
ügyfelei működésüket a keresztezett erőforrások mélysége alapján
optimalizálhatják. Az ügyfelek az erőforrást keresztezhetik saját kezűleg,
illetve az erőforrást és a mélységet bemenetként használhatják egy művelet
során, amelynek a művelet a feladat elvégzését delegálja. Ha például
a felhasználó CVS frissítést végez egy java csomagon, és a java csomag
erőforrás-leképezései egy 1-es mélységű mappára mutatnak, akkor a CVS
kiadja a megfelelő parancsot (jelen esetben ez a "cvs update -l"), amely
azután a csomag által képviselt mappán elvégez egy felszínes frissítést.
Ugyan lehetséges bejárási utak egy csoportját közvetlenül a kijelölt erőforrás-leképezésekből lekérdezni, léteznek olyan modellviszonyok (és lerakatviszonyok), amelyek szükségessé tehetik további erőforrások és modellelemek befoglalását egy műveletbe. Azt, hogy milyen módon biztosítható, hogy a művelet valamennyi szükséges erőforrást tartalmazza, a következő fejezet tárgyalja.
Csoportos műveletek esetében a kijelölt leképezéseket le kell fordítani a művelet céljaként megadott leképezések halmazára. Ez a folyamat magában foglalja a kapcsolatfelvételt valamennyi modellszolgáltatóval annak érdekében, hogy azok biztosan szerepeljenek a felkészítési szabályaiknak megfelelő erőforrásokat érintő műveletekben. Az erőforrás-leképezések teljes halmazát, amelyen a művelet végrehajtásra kerül, a művelet hatókörének hívjuk. Erre az alábbi alkalmazás programozási felületet biztosítjuk:
ISynchronizationScope
:
A művelet hatókörének lekérdezéséhez használt alkalmazás programozási
felületet meghatározó felület. A felület hozzáférést biztosít az összes
érintett erőforrás-leképezéshez, illetve a leképezésekhez tartozó, a
hatókörépítési folyamat során meghatározott bejárási utakhoz. ISynchronizationScopeManager
:
A hatókör létrehozására és kezelésére szolgáló alkalmazás programozási
felületet meghatározó felület. SynchronizationScopeManager
:
Kiterjeszthető osztály, amely az ISynchronizationScopeManager
API egy alapértelmezett megvalósítását biztosítja. ModelOperation
:
Kiterjeszthető működési osztály, amely egy biztosított hatókörkezelő
segítségével hatókört állít elő, illetve rákérdez, hogy a szolgáltató
miatt további erőforrásokat és leképezéseket tartalmaz-e a művelet. A SynchronizationScopeManager
osztály
initialize(IProgressMonitor) metódusa kezeli azt a teljes
folyamatot, amely során a bemeneti erőforrás-leképezések átalakításra
kerülnek a művelet céljaként megjelölt teljes leképezéshalmazzá, illetve
az ezen leképezéseket lefedő teljes bejárásiút-halmazzá. A
lerakatszolgáltatók a folyamatot az alábbi módokon képesek személyre
szabni:
RemoteResourceMappingContext
biztosításával, amely az
erőforrás-leképezések erőforrás bejárási utakból történő lekérdezése
során használható. SynchronizationScopeManager
újradefiniálásával,
amelynek segítségével a hatókörkezelő folyamat igény szerint módosítható. Az alábbi két szakasz részletesen tárgyalja az előzőekben ismertetett pontokat.
Annak biztosítására, hogy a csoportműveletek tartalmazzák az összes szükséges erőforrást, a modellszolgáltatónak szüksége lehet arra a képességre, hogy bepillantást nyerhessen a lerakatban található egy vagy több erőforrás állapotába. Bizonyos modellek esetében erre lehet, hogy nincs szükség. Például a java csomagok 1-es mélységig vizsgált tárolók, a modell távoli állapotától függetlenül. Ezt figyelembe véve a lerakatszolgáltatók könnyen meghatározhatják, hogy a kimenő törléseket véglegesítéskor végre kell-e hajtani, illetve hogy a bejövő kiegészítéseket frissítéskor telepíteni kell-e. Azonban bizonyos esetekben a logikai modelleket alkotó erőforrások idővel változhatnak. Például egy adott modellelemet alkotó erőforrások változhatnak egy leírófájl (vagy egyéb hasonló mechanizmus) tartalmának függvényében. Annak érdekében, hogy az erőforrás-leképezés a megfelelő bejárási utat adja vissza, hozzáféréssel kell rendelkeznie a távoli leírófájl tartalmához (amennyiben az eltér a helyi fájl tartalmától). A folyamat ezáltal tudja ellenőrizni, hogy léteznek-e olyan további erőforrások, amelyeket tartalmaznia kell. Lehetséges, hogy ezen további erőforrások nem léteznek a munkaterületen, de a lerakatkezelő ebben ez esetben is tudja, hogy milyen módon győződhet meg ezek létezéséről a kijelölt művelet elvégzésekor.
Az ilyen és ehhez hasonló, összetettebb modellek támogatásához egy
RemoteResourceMappingContext
adható át a
ResourceMapping#getTraversals
metódus számára. Ha kontextus
is meg van adva, akkor a leképezés ennek segítségével tud meggyőződni
arról, hogy a bejárási út az összes szükséges erőforrást tartalmazza. Ha
nincs kontextus megadva, akkor a leképezés feltételezheti, hogy csak a
helyi állapot érdekes.
A távoli erőforrás-leképezési kontextus három alapvető lekérdezést biztosít:
A fentiek közül az első kérdésre adott válasz a végrehajtott művelet típusától függ. Alapvetően a frissítések és összefésülések háromirányú, ezzel szemben az összehasonlítások és cserék (legalábbis a CVS esetében) kétirányú folyamatok.
Az Eclipse csoport API egy Subscriber
osztályt tartalmaz,
amely egy alkalmazás programozási felületet határoz meg a helyi
munkaterület, illetve a távoli kiszolgáló közti szinkronizálási állapot
biztosítására. A rendszer ezen kívül biztosít egy
SubscriberResourceMappingContext
elemet, amely a szükséges távoli állapothoz a
Subscriber
segítségével fér hozzá. A Subscriber
elemmel rendelkező
ügyfelek számára nem igényel többletfeladatot az erőforrás-leképezési
kontextusok lekérdezése.
A hatókör-előállítási és kezelési feladatok személyre szabásának
érdekében a SynchronizationScopeManager
osztály
továbbszármaztatható. A hatókörkezelő továbbszármaztatásának két fő oka:
ISynchronizationScopeParticipant
felület által meghatározott API segítségével tudnak részt venni. A
SubscriberScopeManager
osztály a SynchronizationScopeManager
egyik
Subscriber
alapú alosztálya, amely a résztvevőket bevonja a
hatókörkezelési folyamatba. Ilyen típusú folyamatokra például az
elemcsoportok esetében van szükség. Ha egy elemcsoport egy hatókör
erőforrás-leképezéseinek egyike, akkor a hatókör által lefedett bejárási
utak halmaza megnőne, ha az elemcsoportba erőforrások kerülnének
felvételre. A lerakatműveletek legfontosabb modellrészvételt igénylő típusa az
összefésülés. Számos esetben a modellek közreműködésére csak fájlszinten
van szükség. Erre a célra került bevezetésre az
IStorageMerger
API, amely lehetővé teszi a modellszolgáltatók
számára, hogy adott kiterjesztéssel vagy tartalomtípussal rendelkező
fájlok összefésüléséhez összefésülőket adjanak közre. Azonban bizonyos
esetekben a modelleknek további kontextusra lehet szükségük ahhoz, hogy
egy összefésülésben megfelelően részt vehessenek. Erre a célra került
bevezetésre az IResourceMappingMerger
és az
IMergeContext
API.
Az összefésülési műveleteket továbbra is a lerakatszolgáltatókhoz tartozó műveletek aktiválják. Azonban azt követően, hogy a felhasználó összefésülés típusú műveletet kezdeményez, a lerakatszolgáltatónak az összefésülési feladatba be kell vonnia a modellszolgáltatókat is annak biztosítására, hogy az összefésülés következtében a modell semmilyen módon se sérüljön meg.
A modell-alapú összefésülés-támogatáshoz két fő lerakatszolgáltató alkalmazás programozási felület kapcsolódik.
A modell-alapú összefésülés egyik fontos szempontja az az API, amely az érintett erőforrások szinkronizálási állapotát továbbítja a modellszolgáltató felé. A szinkronizálási állapot leírására a következő felületek szolgálnak:
Az összes felülethez tartoznak absztrakt osztályok, amelyek neve
egyezményesen megegyezik a felület nevével, az "I" előtag eltávolításával.
Egyedül a ResourceDiff
osztályt kell a lerakatszolgáltatóknak
újradefiniálniuk, hogy a megfelelő módosítás előtti, illetve utáni fájl
felülvizsgálatok biztosítottak legyenek.
Az IMergeContext felület a szinkronizálási kontextust további, az összefésülést támogató metódusokkal terjeszti ki. Visszahívási metódusok az alábbiakhoz léteznek:
A rendszer biztosít egy MergeContext osztályt, amely tartalmazza az összefésüli viselkedés alapértelmezett megvalósítását, és az IStorageMerger segítségével háromirányú összefésüléseket hajt végre. Ezen kívül a rendszer egy SubscriberMergeContext osztály is biztosít, amely az összefésülési kontextushoz tartozó szinkronizálási állapotleírás feltöltését illetve karbantartását kezeli.
A
ModelMergeOperation
műveleti osztály az IResourceMappingMerger
API segítségével
hajt végre modell-alapú összefésülési műveleteket. Az alosztályoknak az
összefésülési kontextus visszaadásához az
initializeContext(IProgressMonitor)
metódust
újra kell definiálniuk. A művelet ezen kontextus segítségével kísérli meg a
megjelenítés nélküli modell-alapú összefésülést. Ha ütközés áll fenn,
akkor az összefésülés előképének előállítása az alosztályra hárul. Amint
azt a következő szakaszban is tárgyaljuk, a
ModelParticipantMergeOperation
a
ModelSynchronizeParticipant
segítségével előképkészítési képességeket biztosít.
A csoportműveletekben található logikai modellek megjelenítésének
támogatása az Eclipse 3.2 változatában bevezetett Általános navigátor
keretrendszeren keresztül történik. A logikai modellek
tartalomkiterjesztéseket és modellszolgáltatókat az
org.eclipse.team.ui.teamContentProvider
kiterjesztési pont segítségével társíthatnak. A csoportszolgáltatók
ezekhez a tartalomszolgáltatókhoz az
ITeamContentProviderManager
segítségével férhetnek hozzá.
Számos olyan hely létezik, ahol a csoportszolgáltató számára fontos lehet a logikai modellek megjelenítése:
ModelOperation
osztály egy parancssort
biztosít, amely a bejegyzett csoporttartalom-szolgáltatók segítségével
értesíti a felhasználót a hatókör bővítéséről. A ModelSynchronizeParticipant
integrációt biztosít a
Szinkronizálási nézetbe, illetve bármilyen egyéb tárolóba, amely képes az
iSynchronizePages
megjelenítésére. A segéd kihasználja mind a
meglévő szinkronizálási segéd, mind az Általános navigátor képességeit,
hogy a csoportszolgáltatók és modellek számára lehetővé tegye az
eszköztár, az előugró menü és az összefésülési nézet egyéb beállításainak
személyre szabását. A ModelSynchronizeParticipant
az
alábbiakat biztosítja:
Az alábbi ellenőrzőlista tartalmazza az akkor elvégzendő lépéseket, ha egy modellszinkronizálási segédet egy adott Csoportszolgáltatóhoz be kíván állítani:
ModelSynchronizeParticipant
alosztályt. ISynchronizePageConfiguration.P_VIEWER_ID
értékét az előző
lépésben megadott megjelenítőazonosítóra. MergeActionGroup
egy egyéni alosztályát biztosítsa. ModelParticipantMergeOperation
egyik
alosztályát a modell-alapú összefésülésről előképre való átállás
kezelése érdekében egy párbeszédablakban vagy Szinkronizálási nézetben. Az alábbi XML kódrészletek a CVS segédosztály bejegyzésének, illetve a hozzá tartozó megjelenítők meghatározásának módját mutatják be.
<extension point="org.eclipse.team.ui.synchronizeParticipants"> <participant name="CVS" icon="$nl$/icons/full/eview16/cvs_persp.gif" class="org.eclipse.team.internal.ccvs.ui.mappings.WorkspaceModelParticipant" id="org.eclipse.team.cvs.ui.workspace-participant"> </participant> </extension> <extension point="org.eclipse.ui.navigator.viewer"> <viewer viewerId="org.eclipse.team.cvs.ui.workspaceSynchronization"> <popupMenu allowsPlatformContributions="false" id="org.eclipse.team.cvs.ui.workspaceSynchronizationMenu"> <insertionPoint name="file"/> <insertionPoint name="edit" separator="true"/> <insertionPoint name="synchronize"/> <insertionPoint name="navigate" separator="true"/> <insertionPoint name="update" separator="true"/> <insertionPoint name="commit" separator="false"/> <insertionPoint name="overrideActions" separator="true"/> <insertionPoint name="otherActions1" separator="true"/> <insertionPoint name="otherActions2" separator="true"/> <insertionPoint name="sort" separator="true"/> <insertionPoint name="additions" separator="true"/> <insertionPoint name="properties" separator="true"/> </popupMenu> </viewer> </extension>
A rendszer egy fájltörténet alkalmazás programozási felülettel bővült, amely lehetővé teszi a modellek számára a fájlok történetének elérését. A fájltörténet API az alábbi felületekből áll:
Az API mellett a rendszer egy általános fájl Történet nézettel is bővült. A nézet lehetővé teszi a Csoportszolgáltatók számára, hogy fájl- és erőforrás-történetet megosztott nézetben jelenítsék meg, illetve lehetővé teszi a modellek számára, hogy a modellelemek történetét megjelenítsék a fájlra közvetlenül nem leképzett elemekre vonatkozóan. A Történet nézet egy olyan oldal-alapú nézet, amely a kijelölt elemre vonatkozó oldalt az alábbi módon szerzi meg:
RepositoryProvider
adaptálásával kerülnek
lekérdezésre, amelyhez az
IHistoryPageSource
az erőforrást tartalmazza. IHistoryPageSource
elemhez adaptálásával
történik. A
ProjectSetCapability
új metódusokkal bővült, amelyek támogatják a projekt és a távoli tartalom
közt fennálló leképezés azonosítására használt referencia-karaktersorozat,
illetve
az org.eclipse.core.filesystem.filesystems
kiterjesztési ponton bejegyzett fájlrendszersémát azonosító URI címek
közötti fordítást. A csoportszolgáltatók ezt akkor támogathatják, ha
lehetővé akarják tenni a logikai modellek számára a távoli böngészést és
projektbetöltést.
A csoportszolgáltatók a modellelemek kiemeléséhez azok könnyű kiemelését átalakíthatják úgy, hogy az erőforrás-leképezéseket kezeljék - hasonlóképpen ahhoz, ahogy az objektum-hozzájárulások az erőforrás-leképezéseket kezelik. Azonban létezik a logikai modellelemek kiemelésének egy problémásabb nézőpontja is. Ha egy modellelem nem rendelkezik kölcsönösen egyértelmű erőforrás-leképezéssel, akkor előfordulhat, hogy a modellelem az alapul szolgáló erőforrások módosításakor egy címkefrissítést nem kap meg.
Ennek a problémának az orvosolására került bevezetésre az
ITeamStateProvider
,
amely a modellszolgáltatók számára hozzáférést biztosít a
csoportkiemeléseket érintő állapotváltozásokhoz. Ezen kívül a
modellnézetek a
SynchronizationStateTester
segítségével is meghatározhatják, hogy a logikai modellelemek címkéit
mikor kell frissíteni. Az API az ITeamStateProvider
felület alapján határozza meg, hogy az erőforrás csoportállapota mikor
változott meg, és átadható egy csoportkiemelő számára egy
IDecorationContext
részeként.