Comment spécifier une entrée Eclipse .classpath pour une plate-forme O / S spécifique?

Question

Je travaille sur un projet SWT en équipe. Nous détruisons constamment l’environnement de construction des autres car le fichier Eclipses .classpath est archivé dans le contrôle de version et nous incluons différentes bibliothèques SWT pour nos machines.

Selon le dernier commis, l'entrée .classpath peut être:

<classpathentry kind="lib" path="lib/swt/swt-win32.jar"/>

ou

<classpathentry kind="lib" path="lib/swt/swt-carbon.jar"/>

ou

<classpathentry kind="lib" path="lib/swt/swt-gtk.jar"/>

Il semble que les bibliothèques s’excluent mutuellement, c’est-à-dire que vous ne pouvez pas toutes les inclure en même temps et laisser SWT résoudre le problème. Nous devons donc les filtrer d'une manière ou d'une autre pour chaque plate-forme ...

Quelqu'un at-il une idée sur la façon de procéder? Mon idée de départ était de scinder cela en son propre & Quot; .classpath-swt & Quot; fichier (ignoré par le VCS), générez-le automatiquement à l’aide de Ant et incluez-le dans le chemin principal .classpath, mais il semble que Eclipse ne prenne pas en charge la division du fichier .classpath.

Notre solution actuelle consiste à éviter de valider le fichier .classpath sauf si nous avons réellement modifié les dépendances. Toutefois, cela signifie qu'un certain nombre de personnes doivent corriger leurs environnements de développement chaque fois que le fichier .classpath est modifié.

Toute suggestion sera très appréciée, à condition que ce ne soit pas & "n'utilisez pas Eclipse &"; comme ce n’est pas une option pour ce projet:)

Answer 1

Eclipse vous permet de définir des variables de chemin de classe afin que vous puissiez conserver le même fichier .classpath, mais chaque développeur configure son Eclipse en fonction de la plate-forme. Vous pouvez au moins alors versionner le fichier .classpath. Vous devrez modifier la structure de répertoires dans laquelle vous stockez vos fichiers JAR SWT afin que le nom du fichier JAR ne change pas par plate-forme. Ce menu se trouve dans: & " Fenêtre - & Gt; Préférences - & Gt; Java - & Gt; Chemin d'accès à la construction &";

SWTJARDIRECTORY/
    WIN32/
        SWT.JAR
    CARBON/
        SWT.JAR
    GTK/
        SWT.JAR

Ex.

    SWT_PLATFORM="SWTJARDIRECTORY/GTK", set by developer in Eclipse

.classpath

    SWT_PLATFORM/SWT.JAR

Answer 2

Vous devriez avoir ces bibliothèques dans un projet séparé, facilement identifiable, au lieu d'être placées dans chaque projet.

E.g. créer un projet nommé " 00-swt-provider " (ainsi il va sur le dessus) et laissez-le référencer l'un de & "00-swt-provider-carbon &", & "00-swt-provider-win32 &"; ou " 00-swt-provider-gtk ".

L'un ou l'autre exporte les bibliothèques natives appropriées pour la plate-forme donnée et le seul lien se trouve dans 00-swt-provider. Le projet actuel fait uniquement référence à ce méta-projet.

Nous utilisons une variante de ce système en interne - cela fonctionne bien pour nous.

Answer 3

Que diriez-vous simplement de configurer vos propres instances et que pour ce composant de votre environnement, vous ne le gardiez pas dans votre contrôle de source?

Vous pouvez également stocker un fichier de chemin de classe pour chaque environnement, peut-être dans un autre répertoire et dans un fichier ant, par exemple, un fichier build-setup-env.xml. Vous pourriez simplement avoir une cible pour chaque environnement et copier le fichier correct. Pour conserver une copie de ceci dans le contrôle de code source, vous devez être sûr de la copier lors de la mise à jour.

Answer 4

SWT le fait en non versionnant le fichier .classpath, mais en versions plusieurs fichiers distincts .classpath_ * avec le système d’exploitation et le système de fenêtre ajoutés, par exemple. .classpath_win32_win32. Ainsi, lorsque vous extrayez les sources du référentiel, vous êtes censé copier le fichier de chemin de classe approprié vers .classpath et recompiler votre projet.