IBM® SCLM Developer Toolkit permet de gérer, de générer et de déployer des
projets Eclipse dans SCLM. Pour utiliser cette fonction, vous devez d'abord mapper le
projet Eclipse avec SCLM. Pour mapper un projet Eclipser avec SCLM,
sélectionnez le projet, cliquez avec le bouton droit, puis sélectionnez
Equipe -> Partager le projet.
La fonction de partage de projet permet de prendre un projet Java™ dans le
plan de travail Eclipse et de le mapper au fournisseur de services de l'équipe SCLM. Chaque fichier source
Java, ainsi que les fichiers apparentés (fichiers .properties et .xml,
par exemple) peut alors être géré par SCLM et stocké comme membres sur le serveur.
Remarque : Une option du panneau principal SCLM ISPF
permet de créer un projet
SCLM pour contrôler le source traditionnel
COBOL et PL/I. Vous pouvez l'utiliser comme point de départ pour développer
votre propre projet SCLM.
Cette forme de structures de projets multiples ne se mappe pas directement à SCLM.
La liaison d'un projet SCLM à un autre projet SCLM qui permet de fournir une
forme
de structure de projets agrégée constitue un inconvénient du fait que SCLM ne
mappe pas réellement les dépendances inter-projet. Néanmoins, en conservant
toutes les sources associées dans un même projet SCLM, SCLM conservera les
dépendances. L'application connaîtra ainsi l'effet que produit un composant sur
un autre en cas de modification.
SCLM offre un moyen permettant de prendre en
charge cette structure IDE à projets multiples dans un même projet SCLM.
Les projets SCLM peuvent être définis avec plusieurs types de source. Chaque
type peut contenir un seul projet. Si nous tentions d'enregistrer plusieurs
projets Eclipse dans SCLM sans une certaine forme de séparation, chaque
fichier .classpath et .project du projet serait remplacé car chaque fichier a
été ajouté à SCLM. L'utilisation de différents types de source permet à ces fichiers et à tous les autres fichiers associés au projet, d'être enregistrés dans SCLM en toute sécurité.
Par exemple :
Avec ce mappage, les projets seraient enregistrés indépendamment dans SCLM
avec le type comme principal élément de différentiation :
Par exemple : EJB1 est enregistré dans le projet SCLM SCLMPRJ1 sous le type
EJB1.
En utilisant cette structure, il est possible de mapper la structure de
projets à des types indépendants dans le projet SCLM.
Remarque : - Il n'est pas nécessaire de mapper un nom de projet dans l'IDE au nom de type SCLM. Ces noms existent indépendamment les uns des autres.
- La longueur des noms de type est limitée à huit caractères, de sorte qu'un
projet IDE appelé "Nouveau projet sans bogues"
ne puisse pas avoir le nom de type
correspondant "Nouveau projet sans bogues". Il faut dans ce cas faire preuve
d'un peu d'imagination : par exemple: "débogué".
Il est donc important que la structure de projet SCLM soit conçue pour permettre le mappage
de différents projets IDE dans sa structure. En effet, dans les grands projets
SCLM, il peut s'avérer utile d'ajouter des types de projet supplémentaires dans
la mesure où cette opération requiert une modification de la définition du
projet SCLM, une régénération de la définition de projet SCLM et l'allocation
de fichiers pour les nouveaux types.
Ce type de structure ne se limite pas aux projets J2EE, mais peut s'appliquer
à toutes les situations dans lesquelles plusieurs projets sont développés,
procurant une certaine forme de dépendance entre eux.
L'utilisation de plusieurs types SCLM pour enregistrer des projets est
également liée à l'opération de la structure ARCHDEF pour la génération de ces
projets.
Le fichier ARCHDEF contient la liste des membres qui constituent une
génération.
Dans le contexte J2EE, une génération peut entraîner la constitution de plusieurs fichiers WAR et JAR dans un fichier EAR. Cette séparation de projets est similaire à la structure de type qui définit le projet dans SCLM. En disposant d'une ARCHDEF de haut niveau qui référence les composants qui
constituent la génération, il est possible d'obtenir un environnement de
génération structuré. Ceci dépend de la définition réelle de la structure de projet lorsque vous définissez les types dans SCLM.
La définition du projet d'une manière structurée permet également :
- La migration des fichiers d'un type de projet SCLM ou ARCHDEF vers un
projet sans avoir à connaître chaque composant.
- La structure ARCHDEF basée sur la définition de type permet également de mapper les dépendances de projet de manière plus efficace. Il est en effet courant que les projets référencent d'autres projets dans
l'espace de travail. Ceci est possible grâce à l'utilisation du mot clé SCLM
INCL dans les ARCHDEF, qui permet d'inclure d'autres projets IDE, référencés
par d'autres ARCHDEF, en imbriquant les ARCHDEF dans des ARCHDEF de niveau
supérieur.
- Lors de la génération d'autres applications ayant des références ou des dépendances sur d'autres objets de génération comme les fichiers JAR, les fichiers de projet ou les fichiers de classe, plusieurs approches
sont possibles :
- Si le projet se rapporte à un fichier JAR, mais qu'il n'est pas destiné
à faire partie du package de génération final, le fichier de bibliothèque peut
être copié dans la CLASSPATH système à l'aide de fonction Charger les fichiers
JAR dans Developer Toolkit. Cette opération aura pour effet de rendre ce service disponible depuis un autre projet SCLM. Au moment de la génération, les références du projet au fichier JAR seront
résolues. Toutefois, pendant l'exécution, le fichier JAR doit être disponible dans une instruction PATH.
- Référencez un fichier JAR qui réside dans le même projet SCLM en utilisant la propriété CLASSPATH_JARS_FILES dans le script de génération.
- Incluez la référence au fichier JAR à l'aide de l'instruction INCLD dans l'ARCHDEF. Cette opération permet de générer l'application avec la référence de bibliothèque dans le package de génération final.
- Incluez le projet en tant qu'ARCHDEF de projet SCLM INCL imbriqué
- Incluez le fichier JAR dépendant dans le répertoire CLASSPATH
Recommandations
- Identifiez la composition du projet J2EE en termes de fichiers EJB,
d'applications Web, etc., pour que cette structure soit définie et puisse être
utilisée pour planifier la structure de projet SCLM
- Pour chaque composant du projet J2EE, créez un type correspondant dans
le projet SCLM. Il est utile de déterminer un type de convention de dénomination explicite pour cela.
- Dans la mesure où les exigences relatives au projet peuvent changer, il est
nécessaire de créer d'autres définitions de type afin de permettre l'ajout
d'autres composants comme des EJBs. L'anticipation de services supplémentaires peut être prévue dans la structure de type.
- Vous pouvez nommer les projets indépendamment du type SCLM, mais une
certaine corrélation facilitera l'administration.
- Le mappage de plusieurs projets dans un seul et même projet SCLM est
pris en charge par la construction de type. Il est également utile d'appliquer une structure de
regroupement prenant en compte la définition de type de ce projet.
- Des conventions de regroupement de type Java doivent également être
définies au niveau du projet afin d'éviter le risque de conflits de dénomination de fichiers source.
- Si l'environnement de développement IDE comporte plusieurs projets, il est
conseillé de répliquer cette structure dans SCLM à l'aide du type utilisant
SCLM.