Il est bon de ne pas ajouter de fichiers .classpath/.project si votre projet est simple et a peu de dépendances externes. En pratique, vous avez souvent un certain nombre de relations à gérer, de sorte que le temps nécessaire pour rendre votre fichier .classpath portable est bien moindre que le coût cumulatif de le redéfinir chaque fois que vous placez le projet dans un espace de travail. Plus votre configuration est impliquée, plus les erreurs subtiles que vous devrez combattre pour tenter de reconstituer la configuration du projet.
Vous devriez être en mesure de configurer votre chemin de classe afin qu'il soit portable en utilisant des variables et des bibliothèques, ceci évite le besoin de coder en dur les chemins. Votre équipe peut convenir d'un ensemble standard de variables (et/ou de bibliothèques) à utiliser. Une variable devrait alors être définie sur la machine de chaque développeur pointant vers les ressources communes que vous utilisez dans votre chemin.
Encore mieux que les variables sont des bibliothèques. Vous pouvez définir des bibliothèques personnalisées (sous Window->Preferences->Java->Build Path->User Libraries
) pour référencer vos composants communs, puis réutiliser ces bibliothèques dans chaque projet. Une bibliothèque configurée peut être exportée depuis la page User Libraries
et utilisée par vos pairs.
Les plugins tels que m2eclipse fournissent des bibliothèques (également appelées Classpath Containers) qui peuvent générer automatiquement du contenu basé sur une certaine configuration (Maven POM dans le cas de m2eclipse). Cela permet d'abstraire les chemins vers les ressources sous-jacentes et permet d'ajouter dynamiquement plusieurs jars au chemin.
Si vous n'utilisez pas Maven, le problème typique .classpath est que vous voulez ajouter tous les jars dans un dossier au classpath. This answer montre comment il est possible de définir un plugin personnalisé pour contribuer tous les jars dans un dossier via un conteneur Classpath, vous pouvez également utiliser cette approche pour attacher automatiquement des sources aux éléments découverts et éviter d'avoir à répéter cet effort à chaque fois.
Voici un exemple typique avant le.classpath pour un projet sur lequel j'ai travaillé récemment. La bibliothèque rend la configuration beaucoup plus lisible, plus portable, permet la réutilisation entre projets et définit les pièces jointes source.
Avant:
<classpathentry kind="src" path="src/main/java"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/xml-apis.jar" sourcepath="C:/apache-ant-1.7.1/src/main"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant.jar" sourcepath="C:/apache-ant-1.7.1/src/main"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-antlr.jar" sourcepath="C:/apache-ant-1.7.1/src/main"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-apache-bcel.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-apache-bsf.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-apache-log4j.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-apache-oro.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-apache-regexp.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-apache-resolver.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-commons-logging.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-commons-net.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-jai.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-javamail.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-jdepend.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-jmf.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-jsch.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-junit.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-launcher.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-netrexx.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-nodeps.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-starteam.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-stylebook.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-swing.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-testutil.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-trax.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/ant-weblogic.jar"/>
<classpathentry kind="lib" path="C:/apache-ant-1.7.1/lib/xercesImpl.jar"/>
Après:
<classpathentry kind="src" path="src/main/java"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<!--all ant jars and source attachments defined here -->
<classpathentry kind="con" path="org.eclipse.jdt.USER_LIBRARY/ant"/>
Je me demandais si le unversioning .classpath fera l'affaire. <:/ – Jeune
Utilisez la fonction "user library". Il permet à chaque utilisateur de configurer le chemin d'accès à la bibliothèque nommée localement. le .classpath ne contient que le nom de la bibliothèque. –