Das IBM® SCLM Developer Toolkit ermöglicht die Verwaltung, die Builderstellung und das Deployment von Eclipse-Projekten in SCLM. Wenn Sie dieses Feature nutzen möchten, müssen Sie zunächst eine Zuordnung des Eclipse-Projekts zu SCLM erstellen. Wählen Sie dazu das Projekt aus, drücken Sie die rechte Maustaste, und wählen Sie
Team -> Projekt gemeinsam nutzen aus.
Bei Verwendung der Funktion 'Projekt gemeinsam nutzen' können Sie ein Java™-Projekt aus der Eclipse-Workbench dem SCLM-Teamserviceprovider zuordnen. Danach kann jede Java-Quellendatei zusammen mit den zugehörigen Dateien (wie .properties und .xml) von SCLM verwaltet und als Member auf dem Server gespeichert werden.
Anmerkung: In der ISPF-basierten SCLM-Hauptanzeige gibt es eine Option für die Erstellung
eines SCLM-Projekts zur Steuerung einer traditionellen COBOL- oder PL/I-Quelle. Diese Option können Sie als Ausgangspunkt für die Entwicklung eines eigenen
SCLM-Projekts verwenden.
Diese Mehrprojektstruktur kann nicht direkt in SCLM abgebildet werden.
Von einer Verknüpfung eines SCLM-Projekts mit einem anderen SCLM-Projekt zur Schaffung einer Art modularer Projektstruktur ist abzuraten,
weil SCLM projektübergreifende Abhängigkeiten nicht wirklich zuordnen kann. Wenn Sie jedoch alle zugehörigen Quellen zu einem einzigen
SCLM-Projekt zusammenführen, verwaltet SCLM die Abhängigkeiten, so dass Sie wissen, welche Auswirkungen die Änderungen an einer zugehörigen Komponente für andere Komponenten haben.
SCLM stellt
Optionen bereit, die die Unterstützung der Mehrprojektstruktur innerhalb nur eines SCLM-Projekts ermöglichen.
SCLM-Projekte können mit mehreren Quellentypen definiert werden. Unter jedem dieser Typen kann ein Projekt gespeichert werden. Wenn Sie versuchen würden,
mehrere Eclipse-Projekte ohne eine gewisse Form der Separierung in SCLM zu speichern, würden beim Hinzufügen von Projekten zu SCLM die Dateien eines Projekts
mit den Erweiterungen .classpath und .project die entsprechenden Dateien eines anderen Projekts überschreiben. Durch die verschiedenen Quellentypen können diese Dateien und alle anderen dem Projekt zugeordneten
Dateien sicher in SCLM gespeichert werden.
Beispiel:
Bei dieser Zuordnung mit dem Typ als Hauptdifferenzierungsmerkmal werden die Projekte
unabhängig voneinander in SCLM gespeichert.
EJB1 wird beispielsweise im SCLM-Projekt SCLMPRJ1 unter dem Typ
EJB1 gespeichert.
Auf diese Weise können Sie die Projektstruktur auf unabhängigen Typen innerhalb des SCLM-Projekts
"abbilden".
Anmerkung: - Es ist nicht notwendig, einen Projektnamen in der IDE dem SCLM-Typnamen zuzuordnen. Die Namen existieren unabhängig voneinander.
- Die Typnamen sind auf acht Zeichen beschränkt, so dass der Name
'Neues fehlerfreies Projekt' für ein Projekt nicht übernommen werden kann. Mit ein wenig Vorstellungskraft könnten Sie beispielsweise den Namen
'0Fehler' wählen.
Aus diesem Grund ist es wichtig, die SCLM-Projektstruktur zu planen, damit die
verschiedenen IDE-basierten Projekten in der Struktur eines SCLM-Projekts abgebildet werden können. Bei umfangreichen
SCLM-Projekten kann es durchaus schwierig sein, zusätzliche Projekttypen hinzuzufügen, da dies
eine Änderung der SCLM-Projektdefinition, eine Neuerstellung der Projektdefinition und das Anlegen von Dateigruppen für die neuen Typen
erfordert.
Diese Art der Projektstruktur ist nicht auf
J2EE-Projekte beschränkt, sondern kann auf jede Situation angewendet werden, in der mehrere Projekte entwickelt werden, die in gewisser Weise voneinander
abhängig sind.
Die Verwendung unterschiedlicher
SCLM-Typen für das Speichern einzelner Projekte korrespondiert auch mit der
ARCHDEF-Struktur für die Builderstellung dieser Projekte.
Die ARCHDEF-Datei enthält die Liste der Dateien, aus denen ein Build erstellt wird.
Im J2EE-Kontext erstellt der Buildprozess eine EAR-Datei, die sich aus einer Reihe von WAR- und JAR-Dateien
zusammensetzt. Diese Untergliederung eines Projekts ist mit der Typstruktur vergleichbar, die das Projekt in SCLM definiert. Durch eine High-Level-ARCHDEF, die
die Komponenten für einen Build referenziert, ist eine strukturierte Buildumgebung möglich. Diese hängt jedoch eng mit dem effektiven Festlegen der Projektstruktur durch das Definieren von Typen in SCLM zusammen.
Das Definieren eines strukturierten Projekts ist die Voraussetzung für Folgendes:
- Dateien von einem SCLM-Projekttyp oder von einer
ARCHDEF können ohne Kenntnis einzelner Komponenten in ein Projekt migriert werden.
- Die auf den Typdefinitionen basierende ARCHDEF-Struktur ermöglicht eine effektivere Zuordnung von Projektabhängigkeiten. Es ist üblich, dass Projekte andere
Projekte im Arbeitsbereich referenzieren. Dieser Ansatz wird durch das
SCLM-Schlüsselwort INCL in ARCHDEFs unterstützt, denn andere Projekte können, referenziert von anderen ARCHDEFs,
aufgenommen werden. Zu diesem Zweck werden die ARCHDEFs in High-Level-ARCHDEFs verschachtelt.
- Für die Erstellung von Anwendungen mit Referenzen auf andere Buildobjekte (z. B. JARs, andere Projekte oder andere Klassen) bzw. Abhängigkeiten von solchen Buildobjekten
gibt es verschiedene Herangehensweisen:
- Wenn das Projekt auf eine JAR verweist, die jedoch nicht Teil des endgültigen Buildpakets sein muss, kann die Bibliotheksdatei
mit dem Service 'JARs hochladen' des
Developer
Toolkit in den Systemklassenpfad kopiert werden. Damit wird dieser Service von einem anderen SCLM-Projekt aus verfügbar. Zur Buildzeit werden die Projektreferenzen auf die JAR aufgelöst. In der Laufzeit muss die JAR jedoch in einer PATH-Anweisung
verfügbar sein.
- Sie können eine in demselben SCLM-Projekt enthaltene JAR mit der Eigenschaft
CLASSPATH_JARS_FILES im Build-Script referenzieren.
- Nehmen Sie den Verweis auf die JAR mit der Anweisung INCLD in die
ARCHDEF auf. Der Buildprozess integriert dann die Bibliotheksreferenz in das resultierende Buildpaket.
- Nehmen Sie das Projekt mit INCL als verschachtelte SCLM-Projekt-ARCHDEF auf.
- Nehmen Sie die abhängige JAR in das Klassenpfadverzeichnis auf.
Empfehlungen
- Identifizieren Sie die EJBs, Webanwendungen usw., aus denen das J2EE-Projekt aufgebaut ist. Die so definierte Struktur können Sie dann für die Planung der
SCLM-Projektstruktur verwenden.
- Erstellen Sie für jede der J2EE-Projektkomponenten einen entsprechenden Typ im SCLM-Projekt. Es ist hilfreich, dies durch eine Konvention für aussagefähige Namen
zu unterstützen.
- Da sich die Projektanforderungen ändern können, ist es ratsam, zusätzliche Typdefinitionen zu erstellen, damit weitere Komponenten (z. B. zusätzliche EJBs) später
reibungslos hinzugefügt werden können. Durch eine vorausschauende Gestaltung der Typstruktur können Sie die eventuelle Aufnahme zusätzlicher Services beschleunigen.
- Obwohl die Benennung der Projekte von den SCLM-Typen unabhängig ist, kann eine gewisse Korrelation die Verwaltung vereinfachen.
- Die Zuordnung mehrerer Projekte zu einem SCLM-Projekt wird durch das Typkonstrukt
unterstützt. Es ist sinnvoll, eine Paketstruktur zu entwickeln, die die Typdefinition für das jeweilige Projekt
berücksichtigt.
- Außerdem sollten Sie auf Projektebene Java-Paketkonventionen definieren, um möglichen Namenskonflikten vorzubeugen.
- Wenn die IDE-Entwicklungsumgebung in mehrere Projekte gegliedert ist, ist es ratsam, diese Struktur in SCLM mit Hilfe der Typen zu replizieren.