Hudson + JUnit + intégré GlassFish, comment fournir la configuration de domaine?

Question

J'utilise NetBeans et GlassFish 3.0.1 pour créer une application EJB3. J'ai écrit quelques tests unitaires, qui sont exécutés via JUnit et utilisent le GlassFish intégré. Chaque fois que j'exécute ces tests sur ma machine de développement (donc depuis NetBeans), tout va bien. Maintenant, je voudrais laisser Hudson faire ces tests. À l'heure actuelle, il ne parvient pas à l'échec de la recherche d'une ressource (dans ce cas, la source de données à une unité de persistence JPA):

[junit] SEVERE: Exception while invoking class org.glassfish.persistence.jpa.JPADeployer prepare method 
[junit] java.lang.RuntimeException: javax.naming.NamingException: Lookup failed for 'mvs_devel' in SerialContext 

Après avoir cherché autour et essayer d'apprendre à ce sujet, je crois qu'il est lié à l'embedded GlassFish n'a pas été configuré avec des ressources. En d'autres termes, il manque un fichier domain.xml. Droite?

Deux questions:

1. Pourquoi fonctionne avec NetBeans sur ma boîte de dev? Quelle magie fait NetBeans en arrière-plan?
2. Comment dois-je fournir le fichier? D'où vient le GlassFish incorporé sur la Hudson-box?

Hudson utilise les mêmes scripts de construction Ant (créés par NetBeans).

J'ai lu this post à propos de instanceRoot et EmbeddedFileSystemBuilder, mais je ne comprends pas assez de cela. Est-ce nécessaire pour chaque TestCase (l'Emb. GF est démarrée/arrêtée pour chaque bean-under-test)? Est-ce que cette partie de EJBContainer.createEJBContainer()? Encore une fois, pourquoi n'est-il pas nécessaire de le faire lors de l'exécution de tests sur NetBeans?

Mise à jour Suivant les conseils de Peter Je peux confirmer: quand fourmi en cours d'exécution sur une copie fraîchement extrait du code, avec les mêmes propriétés que hudson est configuré, les tests sont exécutées!

Answer 1

10-1 il s'agit d'un problème de classpath car les EDI ont tendance à permuter les chemins d'entrée et de sortie selon que vous exécutez normalement ou unittests. Essayez d'exécuter les tests sur une ligne de commande à partir d'une version récemment extraite de votre SCM. Les chances sont que vous aurez la même erreur. Le débogage sur votre machine locale est beaucoup plus facile que sur une machine distante.

Lorsqu'il est construit de façon fiable sur la ligne de commande (dans un répertoire séparé), il est temps de passer à hudson.