Quelle est la meilleure façon de permettre à une équipe de programmeurs d'utiliser Netbeans, Eclipse et IntelliJ sur le même projet, éliminant ainsi la question «quel IDE est le mieux».Support multi-IDE en Java pour une seule équipe
Quels fichiers doivent ou ne doivent pas être vérifiés dans le contrôle du code source?
Je pense que le meilleur moyen est de rendre le processus de construction indépendant de l'IDE. Cela signifie que votre projet ne doit pas s'appuyer sur des fichiers spécifiques à l'EDI pour construire, mais plutôt utiliser un système de construction externe, comme Apache Maven, Apache Ant, ou même créer des scripts personnalisés. Maven est pris en charge par les IDE Java les plus populaires, directement ou via des plug-ins. Si vous ne souhaitez pas utiliser de systèmes de construction externes, vous devez au moins rendre le projet aussi facile à configurer que possible (par exemple en disposant de dossiers standard pour les bibliothèques partagées et autres dépendances). Lorsque je travaillais sur des équipes avec plusieurs IDE dans le passé, j'ai passé de loin le plus de temps à résoudre les dépendances, car les conditions préalables à la construction du projet ont changé avec le temps. Dans le pire des cas, il se peut même que les développeurs ne se soucient pas d'obtenir la dernière version du référentiel de contrôle de version, car ils pensent que la configuration du nouveau projet est un véritable problème.
Si votre projet comporte de nombreuses dépendances de bibliothèque, je pense qu'il est judicieux de les rendre disponibles sous forme binaire dans le référentiel de contrôle de version. De cette façon, les utilisateurs n'ont pas à résoudre toutes les dépendances des dépendances et ainsi de suite juste pour construire un seul projet. Cela nécessite toutefois que vous ayez quelqu'un responsable de garder les binaires "officiels" à jour chaque fois qu'ils changent. (C'est à peu près la même philosophie utilisée par le dépôt Maven, mais les principes peuvent être appliqués manuellement même si Maven n'est pas utilisé.)
Eh bien, c'est une question assez auto-réponse.
Les fichiers à ne pas vérifier dans le contrôle de source sont des fichiers qui ont à faire avec les IDE eux-mêmes.
Laissez aux développeurs le soin de générer ces fichiers. Si vous utilisez Maven, il peut générer des fichiers tels que .project et .classpath pour vous. Eclipse en général est très facile à utiliser avec une structure de fichier de base (avec la nouvelle option Java Project).
Je pense que Maven a également le support de Netbeans, mais pas sur IntelliJ. Le site de Maven est le maven.apache.org.
Il existe de nombreuses considérations lors de l'utilisation de plusieurs jeux d'outils au sein de la même équipe de projet. Par exemple, mon équipe a des développeurs Java utilisant IntelliJ et la plupart des développeurs frontaux (JSP/CSS/HTML) utilisant eclipse. Nous sommes en train de migrer les utilisateurs Eclipse vers IntelliJ à cause de certains plugins IntelliJ que nous avons développés et qui fournissent un support étendu pour notre environnement. Nous n'allons pas développer les plugins pour plusieurs plates-formes, donc nous standardisons IntelliJ à tous les niveaux.
En termes de fichiers spécifiques, je peux parler à IntelliJ. Nous avons vérifié nos fichiers .ipr et nos fichiers .iml. Ne pas archiver les fichiers .iws. Si vous avez également des utilisateurs Eclipse, configurez votre projet IntelliJ pour qu'il lise/stocke les informations de dépendance dans le fichier .classpath et validez-les sur votre VCS.
Pour chaque IDE qui a plus d'un développeur, archivez tous les fichiers de support. Pourquoi réinventer la roue à chaque bureau.
Je l'ai fait avec de nombreux IDE différents, et je n'ai pas encore vu un conflit de noms de fichiers. En fait, même lorsqu'un seul développeur utilise un IDE particulier, il a l'avantage de mettre à jour les fichiers de support, pour la même raison que vous exécutez les autres fichiers dans votre environnement de développement: historique, différé, commentaires, etc.
Il est important de faciliter la vie des développeurs afin qu'ils puissent se joindre au projet et se mettre en marche instantanément – anjanb
En effet, une autre raison. Sur mon projet actuel, j'estime que nous économisons une douzaine d'heures par développeur qui peut tirer les configs IDE avec la source. –
Pour Eclipse, il s'agit des fichiers .classpath et .project. Mon équipe utilise Maven et il est déconseillé aux développeurs de vérifier les fichiers spécifiques à Eclipse. Parce qu'ils peuvent être générés à partir de Maven, ces fichiers sont redondants. De plus, la vérification des fichiers spécifiques au projet semble gagner du temps, mais elle finit généralement par être pénible en raison des variations dans les postes de travail des différents développeurs, ce qui se traduit par des pertes de temps dans les fichiers IDE. La seule façon de contourner cela est de forcer tout le monde à configurer son environnement de la même manière, ce qui va à l'encontre de l'approche agnostique de l'IDE.
Typiquement, je considérerais ceci comme une mauvaise idée. Je ne suis pas sûr de quel type d'environnement c'est (peut-être open source?), Mais il serait vraiment nul pour soutenir plusieurs IDE. Une chose que je recommanderais si cela est inévitable, serait de normaliser vos constructions dans les scripts ant.Si vous avez un grand nombre de dépendances, cela peut être le moyen le plus simple d'obtenir une construction prévisible sur toutes les plates-formes.
Si l'un des IDE se trouve être RAD (basé sur eclipse), il existe un dossier complet appelé .settings que vous ne souhaitez pas inclure dans le SCM.
Quel est le problème avec l'utilisation de plusieurs IDE? Si vous ne faites rien d'spécifique à un IDE (comme utiliser l'éditeur graphique d'Eclipse), alors cela fonctionnerait bien. – Herms
Nous prenons intentionnellement en charge plusieurs IDE à partir du même référentiel SVN. Notre idée était que nous voulions nous assurer que, si une nouvelle personne rejoignait l'équipe ou que quelqu'un devait commencer à travailler sur une nouvelle machine, nous voulions qu'elle puisse vérifier la base de code, l'importer dans l'IDE et avoir immédiatement un travail ... configuration possible. Ce qui signifie que les développeurs ne doivent pas commettre leurs modifications aux fichiers IDE. Tout le reste (par exemple, src, test, lib et ainsi de suite) devient l'ensemble que nous mettons normalement à jour et commons tous les jours.
L'avantage est que nous avons complètement éliminé les guerres IDE ici: les gens Netbeans et Eclipse vivent en parfaite harmonie (en regardant les gens IntelliJ, mais bon ... ;-).
Nous renommons nos fichiers IDE pour l'archivage avec une extension supplémentaire .deletethis ou similaire. Quand une nouvelle personne vérifie le projet, elle supprime simplement l'extension supplémentaire et est prête à partir. De cette façon, nous évitons les conflits de contrôle de source avec les fichiers du projet lorsque les gens modifient leur environnement. Et vous n'avez pas à vous soucier d'éduquer de nouveaux développeurs pour ne pas vérifier ces fichiers.
Pour plus de commentaires et réponses sur ce sujet, voir this question (How do you handle different Java IDEs and svn?)
Pour construire sur cette réponse, voir http://maven.apache.org/plugins/index.html. Près du fond sont des plugins pour Eclipse et IDEA. Vous chargez le projet dans votre IDE (sans les fichiers spécifiques IDE, puis laissez le plugin créer ces fichiers pour vous.) –
Les plugins NetBeans sont ici: http://mojo.codehaus.org/plugins.html ... pourquoi? –
Les projets générés n'incluent pas les paramètres de configuration spécifiques au projet pour les plugins que vous pourriez avoir.Pas une grosse affaire lorsque vous bootstrap, mais gardez-le à l'esprit lorsque vous actualisez – ddimitrov