Voilou, j'utilise (ou plus exactement, j'aimerais utiliser) hansel pour me guider dans l'écriture des tests unitaires. Je suis sous eclipse et j'ai déjà utilisé la bestiole avec succès dans le passé (sur eclipse 2).
 
Mais j'ai un problème, décrit dans la FAQ : http://hansel.sourceforge.net/doc/FAQ.html#Q8
 
En gros, on me dit que le BCEL qui est chargé ne vient pas du bcel.jar que je lui donne explicitement dans le classpath.
 
La question est donc : comment trouver le BCEL qui est chargé, et comment le virer (proprement) ? La simple commande "locate bcel" me révèle que le plugin ant embarque sont propre BCEL, mais je ne vois pas pourquoi il serait dans le classpath de mon application.
 
J'ai comme l'impression d'être dans le problème du "DLL hell" là.
 
merci à mon sauveur, que la paie soit sur vous, et grouillez-vous de vous préparer, vous allez être à la bourre à la messe.

bcel.getClass().getClassLoader() ?

org.apache.bcel.util.ClassLoader.class.getClassLoader() vaut null.

beh

c'est pas ce que Lorill t'as dit d'essayer ...

comme c'est un constructeur qui merde, j'ai pas accès à l'instance, j'ai donc utilisé .class au lieu de getClass().
C'est pas bon ?

si mais pkoi tu as appelé ca sur une classe qui s'apelle ClassLoader, c'est un peu bizarre ...
 
puis bon, Class.getClassLoader est jamais sensé retourner null, je pense

c'est parce que hansel c'est un outil de couverture de code au statement près.
 
Il charge la classe avec un classloader spécial qui trafique le code de la classe à tester. Il se trouve que mon erreur est au moment de l'instanciation de ce classloader.
 
En fait dans le constructeur du classloader de hansel, il y a un appel à super(machin, bidule). La superclasse, c'est un classloader de BCEL qui dans certaines version n'a pas le constructeur avec comme arguments machin et bidule.

houlà ... ca a l'air trop spécifique pour que je puisse t'aider sans bien connaitre le bignou ...

putain, c'est quand même con d'avoir un problème qui est dans la faq et de pas arriver à le résoudre facilement quand même !

t'a essayé en virant le contenu du plugin ant temporairement, pour écarter définitivement la thèse du conflit de classpath ? g eu la même couille avec un autre truc, g du passer temporairement par une install extérieure d'ant pour résoudre le bordel...

non, j'ai peur de tout niquer et j'ai besoin du plugin ant, qu'il conflicte ou pas.

ca se bypass :  
 
en fait l'appel à ANT se fait avec ce qu'il y a dans le ANT_HOME...qui dans les préférences est réglé pour pointer sur le plugin eclipse.
 
Dl toi la 1.6.1, dézippe là qqpart, et fait toi une variable d'environnement anthome comme dit dans le manuel, et fait que eclipse cherche ant dedans.
 
Dans ce rep, t'a plus qu'à trouver le truc du BCEL et le virer...
 
comme ca si va foire, tu peux retrouver ton plugin ant tout bo tout propre qui n'a pas bougé...

bordel, j'ai déjà repondu à cette question 3 fois

ben ça fera 4

class.getProtectionDomain().getCodeSource().getLocation()

euh ça marche au fait?

non, pas dans ce cas précis, mais de manière générale ça marche.