Lerakaterőforrás-kezelés

A RepositoryProvider létrehozása után a következő erőforrás-kezelési mechanizmusokat kell megérteni:

Figyelmen kívül hagyott fájlok

Számos esetben nem szükséges adott fájlokat lerakatvezérlés alatt tartani. A meglévő erőforrásokból származtatott erőforrások például gyakran lekérhetők a lerakatból. A lefordított forrásfájlok (mint a Java ".class" fájlok) például lekérhetők, mivel a megfelelő forrásfájl (".java") megtalálható a lerakatban.  Elképzelhető, hogy a lerakatszolgáltatók által előállított metaadat-fájlok verziókövetése nem javasolt.  Az org.eclipse.team.core.ignore kiterjesztési pont segítségével a szolgáltatók megadhatják azokat a fájltípusokat, amelyeket a lerakatszolgáltató-műveletek esetén figyelmen kívül kell hagyni. A CVS ügyfél például az alábbit adja meg:

<extension point="org.eclipse.team.core.ignore">
<ignore pattern = ".#*" selected = "true"/>
</extension>

A leírónyelv egyszerűen megad egy fájlnévmintát, amelyet figyelmen kívül kell hagyni, egy kiválasztott attribútumot, amely a beállítások párbeszédablakban megadja a fájltípus alapértelmezett választási értékét. Végül a felhasználónak el kell döntenie, hogy mely fájlok legyenek figyelmen kívül hagyva. A felhasználó fájltípusokat törölhet, jelölhet ki vagy megszüntetheti a kijelölést a figyelmen kívül hagyott fájlok alapértelmezett listájában.

Fájltípusok

Néhány lerakat különböző kezelést vaslósít meg a szöveges illetve bináris fájlokhoz. Az org.eclipse.team.core.fileTypes kiterjesztés segítségével a bedolgozók a fájltípusokat szöveg- vagy bináris fájlként deklarálhatják.  A Java eszközkezelés például az alábbit adja meg:

<extension point="org.eclipse.team.core.fileTypes">
<fileTypes extension="java" type="text"/>

<fileTypes extension="classpath" type="text"/>
<fileTypes extension="properties" type="text"/>
<fileTypes extension="class" type="binary"/>

<fileTypes extension="jar" type="binary"/>
<fileTypes extension="zip" type="binary"/>
</extension>

A leírónyelv segítségével a bedolgozók a fájltípust kiterjesztés alapján adhatják meg, és hozzárendelhetnek egy szöveges vagy bináris típust. A figyelmen kívül hagyott fájlokhoz hasonlóan végül a felhasználó kezeli a szöveges és bináris fájltípusok listáját.

Csapat- és csatlakoztatott erőforrások

A projekt tartalmazhat olyan erőforrásokat, amelyek nem a projekt könyvtárában találhatók a helyi fájlrendszeren. Ezekre az erőforrásokra csatolt erőforrásokként hivatkozunk.

Következmény a lerakatszolgáltatók számára

A csatolt erőforrások kihívásokat támaszthatnak a lerakatszolgáltatókkal szemben, amelyek közvetlenül a fájlrendszeren működnek. Ez annak a következménye, hogy a csatolt erőforrások kialakítás szerint nem léteznek a fájlrendszer közvetlen címjegyzék projektkönyvtárfájában.

Az alábbi jellemzőket mutató szolgáltatókra hatással lehetnek a csatolt erőforrások:

  1. Azokra, amelyek egy külső programot hívnak meg, amely azután közvetlenül a fájlrendszeren működik.
  2. Azokra, amelyek az IResource tagjaiban kerülnek megvalósításra, de feltételezik, hogy a projekt összes fájlja/mappája ezen gyökérrel rendelkező könyvtárfa közvetlen leszármazottja.

Az első esetben tételezzük fel, hogy a felhasználó kiválaszt egy csatolt erőforrást, és megpróbál végrehajtani rajta egy szolgáltatóműveletet. Mivel a szolgáltató egy parancssori ügyfelet hív meg, feltételezhetjük, hogy a szolgáltató az IResource.getLocation().toOSString(), első meghívásának megfelelő dolgot hajtja végre, az eredményül kapott fájlrendszert pedig a parancssori program argumentumaként biztosítja. Ha a kérdésben szerepelő erőforrás egy csatolt erőforrás, akkor ez a projektkönyvtárfán kívüli fájlt/mappát eredményez. Nem az összes parancssori ügyfél tudja kezelni ezt az esetet. Röviden: ha a szolgáltató megtudja az erőforrás fájlrendszer-helyét, akkor valószínűleg többletmunkát igényel a csatolt erőforrások kezeléséhez.

A második eset nagyon hasonló abban az implicit feltételezésben, hogy a projekt-erőforrások struktúrája 1:1 a fájlrendszer fájljaival/mappáival. Általában a szolgáltató bajba kerülhet, ha keveri az IResource és java.io.File műveleteket. Hivatkozások esetén például az IFile szülője nem egyezik meg a java.io.File szülőjével, és a kód, amely feltételezi ezek egyezését, meghiúsul.

Visszamenőleges kompatibilitás

Fontos volt, hogy a csatolt erőforrások bevezetése ne szakítsa meg véletlenül a meglévő szolgáltatókat. A szolgáltatók problémája, hogy érthető módon feltételezték, hogy a helyi fájlrendszer struktúra tükrözte a projektstruktúrát. A csatolt erőforrások alapértelmezésben nem adhatók a projektekhez, amelyek ilyen szolgáltatóra vannak leképezve. A csatolt erőforrásokat tartalmazó projektek alapértelmezés szerint nem oszthatók meg ezzel a szolgáltatóval.

A csatolt erőforrások kezelési stratégiái

A csatolástámogatás érdekében a szolgáltatóknak engedélyezniük kell a csatolt erőforrásokkal rendelkező projektek verziókövetését, de a csatolt erőforrások verziókövetése letiltható.

Ennél lényegesebben bonyolultabb megoldás az aktuális csatolt erőforrások verziókövetésének engedélyezése, de ez ellenjavallt, mivel összetett példahelyzetekkel jelenik meg (például elképzelhető, hogy a fájl verziókövetését más szolgáltató már megvalósította más projektfa alatt). Javaslatunk a verziókövetett projektek támogatása, amelyek nem verziókövetett csatolt erőforrásokat tartalmaznak.

A csatolástámogatás technikai részletei

A lerakatszolgáltató-megvalósítások frissíthetők, hogy támogassák a csatolt erőforrásokat a RepositoryProvider.canHandleLinkedResources() metódus újradefiniálásával, hogy true értéket adjon vissza. Amennyiben ezt megtörtént, a csatolt erőforrások engedélyezettek lesznek a lerakatszolgáltatóval megosztott projektekben. A lerakatszolgáltatónak lépéseket kell tennie annak biztosítása érdekében, hogy a csatolt erőforrások kezelése megfelelően történjen. Ahogy fent említettük, határozottan ajánlott, hogy a lerakatszolgáltatók figyelmen kívül hagyják az összes csatolt erőforrást. Ez azt jelenti, hogy a csatolt erőforrásokat (és leszármazottjaik) ki kell hagyni a lerakatszolgáltató által támogatott tevékenységekből. A lerakatszolgáltatónak az alapértelmezett áthelyezés és törlés viselkedést kell használni a csatolt erőforrásokhoz, ha a lerakatszolgáltató-megvalósítás felülírja az alapértelmezett IMoveDeleteHook csatlakozópontot.

A csapatszolgáltatók az IResource.isLinked() segítségével meghatározhatják, hogy az erőforrás hivatkozás-e. Ez a metódus csak a hivatkozás gyökeréhez ad vissza igaz értéket. Az alábbi kódszegmens segítségével meghatározható, hogy az erőforrás a hivatkozás leszármazottja-e.

String linkedParentName = resource.getProjectRelativePath().segment(0);
IFolder linkedParent = resource.getProject().getFolder(linkedParentName);
boolean isLinked = linkedParent.isLinked();

A lerakatszolgáltatóknak figyelmen kívül kell hagyniuk azon erőforrásokat, amelyek esetén a kód értéke true.

Csapat privát erőforrások

A lerakatmegvalósítások általánosan extra fájlokat és mappákat használnak a lerakatmegvalósítás-specifikus információk tárolásához.  Ezekre a fájlokra szükség van a munkaterületen, más bedolgozókat vagy végfelhasználókat nem érdekelnek.

A csapatszolgáltatók az IResource.setTeamPrivateMember(boolean) segítségével jelzik, hogy az erőforrás privát a csapatszolgáltató megvalósításához. Az újonnan létrehozott erőforrások alapértelmezés szerint nem privát tagok, így ezt a metódust kell használni az erőforrások csapat privátként megjelöléséhez.  Az általános alkalmazás a projekt almappájának csapat privátkénti megjelölése, amikor a csapathoz és almappához létrehozott projekt be van állítva.

Az erőforrásokat (mint például az erőforrás-változásfák) felsoroló más erőforrások kihagyják a csapat privát tagokat, hacsak nincs kifejezetten megadva a tartalmazásuk. Ez azt jelenti, hogy a legtöbb ügyfél nem látja a csapa privát erőforrásokat, és nem jelennek meg más felhasználó számára. Az erőforrás-navigátor alapértelmezés szerint nem jeleníti meg a csapat privát tagokat, de a felhasználók a Beállítások segítségével jelezhetik, hogy szeretnék látni a csapat privát erőforrásokat.

A projekteket vagy munkaterület-gyökér csapat privátként megjelölése figyelmen kívül marad.

Projekthalmazok

Mivel a verziókövetés alatt álló projektek erőforrásai a lerakatban tárolódnak, a projektek a projekt munkaterületen újbóli létrehozásához szükséges lerakatspecifikus információkra mutató hivatkozások megosztásával megoszthatók a csapattagok között. Ez a csapat projekthalmazok speciális fájlexportálás típusával hajtható végre.  

 

A 3.0 verzióban az API hozzáadásra került a ProjectSetCapability elemhez annak engedélyezéséhez, hogy a lerakatszolgáltatók olyan osztályt adjanak meg, amely a projektek mentését a vezérlésük alatt válósítják meg.  Ha a felhasználó a projekthalmazok exportálását választják, akkor csak azon lerakatokkal beállított projektek jelennek meg az exportáláshoz jelöltként, amelyek projekthalmazokat határoznak meg.Ez az API helyettesíti a régi projekthalmaz sorbafejtési alkalmazás programozási felületet (lásd alább).

A lerakatszolgáltató projekthalmaz képességosztálya a RepositoryProviderType osztályból kerül lekérésre, amely ugyanabban a kiterjesztésben van bejegyezve, mint a lerakatszolgáltató. Például:

<extension point="org.eclipse.team.core.repository">
<repository
typeClass="org.eclipse.team.internal.ccvs.core.CVSTeamProviderType"

class="org.eclipse.team.internal.ccvs.core.CVSTeamProvider"
id="org.eclipse.team.cvs.core.cvsnature">
</repository>
</extension>

A 3.0 előtt az org.eclipse.team.core.projectSets kiterjesztési pont lehetővé tette, hogy a szolgáltatók egy olyan osztályt határozzanak meg, amely megvalósítja a projektmentést a vezérlésük alatt álló projektekhez.  Ha a felhasználó a projekthalmazok exportálását választják, akkor csak azon lerakatokkal beállított projektek jelennek meg az exportáláshoz jelöltként, amelyek projekthalmazokat határoznak meg.

A CVS ügyfél például az alábbit határozza meg:

<extension point="org.eclipse.team.core.projectSets">
<projectSets id="org.eclipse.team.cvs.core.cvsnature" class="org.eclipse.team.internal.ccvs.ui.CVSProjectSetSerializer"/>
</extension>

A megadott osztálynak meg kell valósítani az IProjectSetSerializer elemet. Ezen felület használata továbbra is támogatott a 3.0 verzióban, de ez elavult.