Lerakat eligazító a logikai modellintegrációhoz

A logikai modellek teljeskörű támogatásához a lerakatszolgáltatók az alábbi műveleteket tudják elvégezni:

  1. Hozzáadják a megfelelő lerakatműveleteket a ResourceMapping osztályhoz adaptálásra kerülő elemekhez.
  2. Egy 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.
  3. Lehetővé teszik a modellszolgáltatók számára, hogy az 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.
  4. Lehetővé teszik a modellszolgáltatók számára, hogy az összefésülésben résztvevő modellekre vonatkozó 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.
  5. Az 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.
  6. Hozzáférést biztosítanak a távoli konfigurációkhoz az org.eclipse.core.filesystem bedolgozó Eclipse fájlrendszer alkalmazás programozási felületének segítségével, majd azokat a ProjectSetCapability segítségével a munkaterület projektekhez csatolják.
  7. A 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.

Műveletek hozzáadása az erőforrás-kiosztásokhoz

Az alapszintű erőforrás-leképező API

Az erőforrás-leképező API az alábbi osztályokból áll:

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.

Erőforrás-kiosztások és objektumok közreadása

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:

  1. Módosítsa a popupMenus kiterjesztési pont tetszőleges objectContributions tulajdonságát annak saját plugin.xml fájljában úgy, hogy az az IResource helyett a ResourceMapping osztályra mutasson (azokra a pontokra vonatkozóan, ahol ez megfelelő).
  2. Módosítsa ezek műveleteit úgy, hogy azok az 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.

Művelet hatóköre

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:

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:

  1. 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ó.
  2. A 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.

Távoli erőforrás-leképezési kontextus

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.

SynchronizationScopeManager továbbszármaztatása

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:

  1. A lerakatszolgáltatónak további erőforrásokat kell tartalmaznia egy adott lerakatszintű viszony (pl. módosításkészlet) miatt. Ez az adjustInputTraversals(ResourceTraversal[]) metódus újradefiniálásával érhető el.
  2. A szinkronizálás hosszabb életciklussal rendelkezik (pl. Szinkronizálási nézet a Szinkronizálási párbeszédablakkal szemben), és ezáltal szüksége van arra a lehetősége, hogy a hatókörváltozásokra reagálni tudjon. A modellszolgáltatók a hatókörkezelési folyamatban az 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.

Modell-alapú összefésülés

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.

  1. Az összefésülésben résztvevő erőforrások szinkronizálási állapotát leíró API.
  2. A modellszolgáltatók számára a modellelemek összefésülését lehetővé tevő API.
Az alábbi szakaszok ezen két API leírását tartalmazzák.

Szinkronizálási állapot leírására szolgáló API

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.

Modell-összefésülésre szolgáló API

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.

Modelltartalom a csoportmegjelenítőkben

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:

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:

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> 

Fájltörténet

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:

Projekthalmaz képesség

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.

Modellelemek kiemelése

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.