Élaboration d'un projet Java Eclipse sur les deux 32bits et 64bits systèmes Linux

Question

J'ai une série de projets connexes que j'ai placé sous contrôle Git (tous ces projets sont dans le même espace de travail, ce qui est le plus haut niveau du dépôt Git) et clonés à partir de mon bureau (32 bits) à mon ordinateur portable (64 bits) pour que je puisse travailler sur eux partout où. Le dossier de l'espace de travail .metadata est exclu, mais tout dans les dossiers de projet est suivi.

Quand j'ai ouvert l'espace de travail cloné sur l'ordinateur portable, j'ai été accueilli par une erreur:

Project 'project' is missing required library:
'/usr/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_3.5.2.v3557f.jar'

De toute évidence, l'éclipse 64bit n'a pas les bibliothèques 32bit, mais je suis curieux de savoir comment cela devrait être résolu.

Cette bibliothèque a été ajoutée dans le cadre de la fenêtre Builder SWT / JFace modèle de projet. Il y a un org.eclipse.swt_3.5.2.v3557f.jar dans l'éclipse dossier plugins, mais en changeant le classpath de chercher cela ne fonctionne pas (ne trouve pas SWT, curieusement). En regardant à travers le reste du fichier .classpath pour le SWT / JFace projets, cette bibliothèque particulière est le uniquement qui est si spécifique de la plate-forme.

Je mis les deux versions de la bibliothèque dans le .classpath et cela permet le code de construction / run, bien que je dois ignorer l'erreur de chemin de génération, et cette erreur va se propager en arrière sur mon bureau quand je tire l'ordinateur portable change en arrière.

Puis-je créer un lien symbolique le pot de 64 bits sur l'ordinateur portable au nom de 32bit de sorte que le classpath peut trouver la bibliothèque? Y at-il une autre, une meilleure solution?

UPDATE : Il semble que ce type de projet doit dépendre du fragment de SWT en béton, jusqu'à ce qu'il ya une meilleure solution que je vais les fragments en lien symbolique question sur les deux machines pour diriger le compilateur au fragment correct. Construire / la gestion des projets sur d'autres machines (et en particulier Windows) sera !! Fun !! mais je vais construire ce pont quand je suis là.

Answer 1

Qu'est-ce que vous gardez exactement dans votre contrôle de code source?

La meilleure pratique est de ne conserver que les fichiers sources écrits à la main sur référentiel source. Pas binaires, ou les fichiers générés, ou les paramètres IDE.

Je pense que vous avez le problème avec les paramètres IDE Eclipse pour votre 64bit ne fonctionne pas avec un 32bit.

Il suffit de supprimer le répertoire de .metadata dans votre espace de travail et réimporter tous les projets dans ce Eclipse.

Answer 2

Ne pas le faire avec l'espace de travail entier. Il suffit de le faire avec les projets individuels. Fonctionne bien ici.

Answer 3

Quel type de projet vous développez? Le projet java ou plug-in projet?

Si vous développez plug-in projet, votre projet ne devrait pas dépendre directement sur le fragment de béton SWT (comme swt.gtk, swt.win32). Il devrait dépendre du plug-in host « org.eclipse.swt » que la mise en œuvre effective de SWT sont les différents fragments de différentes plates-formes.

Si vous développez un projet java qui nécessite l'SWT comme l'exigence tiers. Vous pouvez installer le paquet delta éclipse pour les deux votre 32bit et 64bit éclipse.

Answer 4

Pour éviter les problèmes de plate-forme, vous pouvez aussi envisager Maven. En utilisant Maven 2 ou 3, avec une combinaison facultative de profils problèmes de plate-forme peuvent être facilement résolus. En utilisant quelques plugins Maven pour Eclipse, les projets Maven peuvent être importés dans Eclipse directement.