Eclipse classpath entrées uniquement utilisé pour des tests

Dans Maven, vous pouvez avoir au moment de la compilation dépendances et test dépendances. C'est une fonctionnalité que j'aime, et le plugin M2Eclipse fait de cette disposition dans Eclipse, trop, ce qui est excellent. Donc, si j'ajoute jmock.jar à mon projet comme un test de dépendance, il montrera sur le chemin de JUnit tests, mais ne sera pas présent lorsque je suis débogage de l'application elle-même.

C'est exactement ce que je voudrais réaliser maintenant, mais sans M2Eclipse ou Maven. Est-il un moyen de le faire dans la plaine de l'Éclipse? (Éventuellement sans installer aucun plugins.)

InformationsquelleAutor Lóránt Pintér | 2009-07-15

9

J'ai peur que la réponse est que vous ne pouvez pas. Il y a 2 questions ouvertes qui ont été reportées à partir de 3,5 liées à votre problème:
- Capacité de marquer dossier source en tant que sources de test
- [buildpath] Devrait être en mesure d'ignorer les avertissements de certains dossiers source
InformationsquelleAutor Robert Munteanu
12

Vous pourriez séparer toutes vos tests dans un autre projet et ajoutez le principal projet en tant que dépendance (Projet->Propriétés->Java Build Path->Projets->Ajouter...)

Mise à jour: Pour éviter de modifier le projet initial de la structure, vos projets de test pouvez utiliser lié endroits.

Créer le projet de test comme d'habitude, vous devez maintenant créer une ressource liée à apporter dans le répertoire src/test/java dossier. Il est préférable de le créer à l'aide d'une variable de sorte que vos projets peuvent conserver une certaine indépendance de plate-forme.
Pour créer un nouveau dossier lié sélectionnez Nouveau->Dossier, entrée src dans le nom du dossier: champ puis cliquez sur Avancé>>

Cliquez sur Lien vers un dossier dans le système de fichiers
Cliquez sur Variables... à mettre en place la Sélectionnez la Variable de Chemin d'accès dialogue.

Si c'est votre première fois ou que vous créez un lien vers un nouvel emplacement, sélectionnez Nouveau... et de donner à la variable un nom judicieux et le chemin d'accès. Si tous vos projets sont situés dans c:\workspaces\foo** il est logique d'appeler la variable **WORKSPACE_ROOT et lui donner un chemin d'accès. Si vous avez une autre convention qui est très bien, mais il est logique de mettre un commentaire dans le .fichier de projet si quelqu'un a une chance de comprendre ce que la valeur correcte doit être.

En supposant que les valeurs ci-dessus, vous pouvez maintenant définir une valeur de WORKSPACE_ROOT/[sous réserve nom du projet]/src sur le champ de saisie

Une fois que vous confirmez que vous devriez voir le dossier src avec une petite flèche, et si vous regardez dans le .fichier de projet voir quelque chose comme ceci:
```
<linkedResources>
    <link>
        <name>src</name>
        <type>2</type>
        <locationURI>WORKSPACE_ROOT/esf-ns-core-rp/src</locationURI>
    </link>
</linkedResources>
```
Vous pouvez maintenant ajouter le répertoire src/test/java dossier dans un emplacement de la source normale.

Remarque vous pouvez également partager le répertoire src/test/java dossier en modifiant la config à quelque chose comme ceci:
```
<linkedResources>
    <link>
        <name>src/test/java</name>
        <type>2</type>
        <locationURI>WORKSPACE_ROOT/my-project/src/test/java</locationURI>
    </link>
</linkedResources>
```
Cela donne plus de contrôle sur la config, mais vous devez la répéter pour la src/test/resources, src/il/java etc.

Vous ensuite de définir toutes les dépendances des tests que dans le projet de test.

Pas très joli, mais il ne fonctionne pas (j'ai aussi utilisé cette où mon test niveau de conformité est différente de la principale niveau de conformité, par exemple, 1,5 pour les tests, mais 1,4 pour l'environnement cible).
- Je fais cela dans une grande application, développée par de nombreuses personnes. J'espère que nous pouvons migrer vers Maven bientôt, donc je n'aurais pas l'esprit de sales tours (qui peut être retiré une fois que nous sommes sur Maven/M2Eclipse), mais la modification de la structure de projet qui est hors de portée à ce point.
- J'ai copié sans vergogne certaines parties de votre réponse dans la mienne (stackoverflow.com/questions/1470827/...), donc +1 😉
InformationsquelleAutor Rich Seller
1

Depuis que vous utilisez à la fois Eclipse et Maven, vous pouvez le contourner.
Créer un nouveau "Maven Build" run configuration avec l'objectif de "exec:java" et les paramètres "exec.mainClass=com.exemple.Starter". De cette façon, le chemin sera calculé par Maven.
- C'est un 4 ans réponse, mais je suis en utilisant STS 3.6.4 (Luna 4.4.2) et il y a le problème et cette solution de contournement est grande. Dans mes tests, j'ai un mannequin @Service qui implémente la même interface que le vrai, et lors de l'éclipse de faisceaux dans les classes de test de Printemps ne peut pas choisir la mise en œuvre du service de l'utiliser. "unique correspondant bean, mais de 2."
InformationsquelleAutor martin-g
0

En fait, si vous regardez dans eclipse comment Maven intègre les dépendances qu'il ne fera pas la différence de test ou les dépendances d'exécution de vos tests les bibliothèques sont toujours accessibles.

Maven conservera la différence lors de l'emballage de la demande et lorsqu'il génère le runtime classpath si maven a le contrôle sur l'exécution de la partie. Lors de l'éclipse est concerné Maven ajoute simplement tous sans que la question de l'éclipse build path.

Pourquoi est-ce vous avez besoin d'avoir cette séparation comme ? Que sera-ce de vous aider à réaliser ?
- C'est comme vous l'avez décrit, si vous n'utilisez pas le plugin M2Eclipse. Mais avec le plugin installé les dépendances étendues sont effectivement appliquées. J'avais besoin de cette séparation, car j'aimerais utiliser des implémentations de journalisation pour les essais et pour l'exécution. Comme SLF4J utilise SPI pour localiser la mise en œuvre effective, je ne pense pas que l'ajout de deux d'entre eux sur le chemin de la classe serait une bonne idée.
- Je suppose que le maven constructeur n'a plus de magie à celle indiquée ensuite. Fondé sur ce que je vois ici votre meilleure option pour le moment (jusqu'à ce que vous obtenez Maven) serait de pirater votre structure de projet Riches comme indiqué ci-dessous, tout en gardant votre dossier en conservant la structure. Dans ce cas, si ce n'est déjà comme ça, vous pourriez aussi bien commencer tout de suite à faire respecter le maven disposition de la convention, cela permettra de faciliter la transition plus tard.
- Je n'étais pas au courant de la SLF4J bibliothèque... merci.. j'ai utilisé pour créer mon propre wrapper bien que mes besoins sont modestes, je n'ai jamais cherché d'autres solutions. merci
InformationsquelleAutor Newtopian
0

Eclipse Photon enfin ajouté cette fonctionnalité, avec m2e soutien.

InformationsquelleAutor Ben

Vous devez vous connecter pour publier un commentaire.