Pourquoi ne pas utiliser groovy classpath argument?
Invoquant un script groovy à l'aide de CLASSPATH préfixe comme suit fonctionne très bien:
CLASSPATH=/path/to/classes groovy -e "(new stuff.XMLUtils()).printIt('test string')"
mais changer pour utiliser le classpath arg n'est pas le cas:
groovy -classpath /path/to/classes -e "(new stuff.XMLUtils()).printIt('test string')"
et donne l'erreur:
script_from_command_line: 1: unable to resolve class stuff.XMLUtils
Quelqu'un peut-il expliquer pourquoi il en est? (Le truc.XMLUtils est juste quelques groovy script que j'ai compilé dans /chemin/vers/classes
)
J'ai fait quelques recherches, et à l'aide de la suite de groovy script pour vider le chargeur de classe
def printClassPath(classLoader) {
println "$classLoader"
classLoader.getURLs().each {url->
println "- ${url.toString()}"
}
if (classLoader.parent) {
printClassPath(classLoader.parent)
}
}
printClassPath this.class.classLoader
Avec le -classpath
arg, je ne vois pas d'entrée dans le chargeur de classe pour le passé dans le classpath arg (en fait, le seul répertoire de travail courant dir), par exemple:
groovy.lang.GroovyClassLoader$InnerLoader@4911b910
groovy.lang.GroovyClassLoader@18203c31
sun.misc.Launcher$AppClassLoader@35a16869
- file:/usr/share/java/ant.jar
- ... (removed for brevity)
- file:/home/admin/groovy/
sun.misc.Launcher$ExtClassLoader@77cde100
- file:/usr/java/jdk1.6.0_23/jre/lib/ext/sunjce_provider.jar
- ...
À l'aide de la CLASSPATH=...
version montre que la DDT de l'entrée ci-dessus est remplacé par la valeur que j'ai mis dans la variable.
Et si j'ajoute de débogage pour le groovy shell exécutable, à la différence de java est l'appel que le -classpath
arg version n'ajoute pas de l'entrée de java le classpath de l'entrée (qui est en fin de compte pourquoi c'est de donner une classe ne trouve pas d'erreur), mais le CLASSPATH=...
version ajouter le chemin d'accès.
Est-ce un bug groovy?
EDIT: simple exemple d'échec de
- - - - xu.groovy
package stuff
def printIt(string) { println string }
- - - -
groovyc -d classes xu.groovy
groovy -cp classes -e "(new stuff.xu()).printIt('test')" # fails
CLASSPATH=classes groovy -e "(new stuff.xu()).printIt('test')" # works
Si je supprime le paquet et les références à stuff
l'exemple d'échec ne fonctionne correctement.
Vous devez vous connecter pour publier un commentaire.
Répondre à cette question à moi-même car j'ai trouvé une solution à ce problème.
J'ai été en utilisant la valeur par défaut groovy paquets de yum dans fedora, cependant trouvé de nombreux problèmes (erreurs de démarrage de groovysh etc, impossible de trouver jline package etc), et ont totalement déplacé à l'aide de versions téléchargées à partir de codehaus.org et spécifiant manuellement GROOVY_HOME et l'édition de chemin à invoquer le télécharger à la place.
Maintenant tous mes exemples fonctionnent comme prévu.
Je suis sur MSYS/Win32 + groovy 2.2 RC1 et ont une autre tournure:
groovy -cp "./*" script.groovy //Fonctionne!
groovy -cp some.jar script.groovy //... pas
Pour une raison quelconque, aucun de ces travaux dans mon cas.
C'est étrange. J'ai juste essayé de répéter vos expliqué question, mais tout semble fonctionner correctement (j'ai fait des tests avec Groovy-Version 1.8.6, 1.7.7 et 1.7.0 sur mon Ubuntu Ordinateur).
Alors, quelle version utilisez-vous et quel est votre système d'exploitation?
Dans le Groovy Bug Tracker, j'ai trouvé le bug suivant: Option de ligne de commande pour classpath (--cp/--classpath) est cassé sur Windows. Mais ce bug affecte les anciennes versions de Groovy (1.5.2, 1.5.3 et 1.5.4). Alors peut-être une mise à niveau de Groovy aidera à résoudre votre problème...
PS: Normalement j'ai juste un commentaire, mais malheureusement, je n'ai pas assez de points pour ce faire :).
Groovy Version: 1.8.0 JVM: 1.6.0_22
.-classpath
ouCLASSPATH=...
si je retire la déclaration de paquet et ont tout défaut au niveau du package, mais dès que j'ajoute lepackage stuff
ligne vers le haut et le compiler, groovy, ne semble pas trouver avec le-classpath
arg. J'ai essayé sur un autre ordinateur exécutant 1.8.4 et toujours le même problème. J'ai mis à jour ma question avec un exemple détaillé.package stuff
déclaration) fonctionne très bien sur ma machine...