Lors de l'exécution de Groovyc dans une enveloppe de Windows, je rencontre des problèmes en raison de la longueur de la classe de classe, dans ma situation. J'aimerais contourner cela en créant un pot de cheminement, puis mettre ce pot sur le CP. Comment créer un pot de cheminement avec toutes les entrées de classePath spécifiées automatiquement en gradle, puis ajoutez ce bocal au CP? P>
3 Réponses :
Voici une solution testée:
task testPathingJar(type: Jar) { appendix = "testPathing" doFirst { manifest { attributes "Class-Path": configurations.testCompile.files.join(" ") } } } compileTestGroovy { dependsOn(testPathingJar) classpath = files(testPathingJar.archivePath) }
WHOA, une réponse de Peter Niederwieser lui-même! Merci! Je vais essayer cela bientôt, espérons-le. BTW, Spock est spectaculaire.
Question de suivi: cela ne semble pas fonctionner comme prévu. Le bocal de cheminement est créé, mais lorsque j'ajoute le pot de cheminement à la classe de classe lors de la compilation, pour une raison quelconque, la compilée échoue et se plaint des bocaux manquants déjà référencés dans le pavillon de cheminement ...
Je pense que cela ne fonctionnera pas, car cela spécifie des chemins absolus des pots dans le manifeste. Il n'est pas clair que les chemins absolus sont valables dans ce cas.
Le problème n'était pas les chemins absolus, mais que le côlon au lieu de l'espace était utilisé comme séparateur de chemin. J'ai mis à jour le code et l'avez testé pour vous assurer qu'il fonctionne.
Je semble me rappeler des tests avec un espace sans aucune chance. Je vais lui donner un coup de feu aujourd'hui et rapporterai.
Oui, cela ne fonctionne pas pour moi. Lorsque j'ai utilisé le bocal de cheminement, la compilée échoue en raison d'une incapacité à localiser les dépendances.
Étrange, travaille pour moi. J'ai même eu une solution qui utilisait des chemins relatifs mais je l'ai jeté après avoir trouvé que les chemins absolus n'étaient pas la cause du problème. Quelle est la taille de votre projet que vous rencontrez dans ce type de problème?
Je dirais que nous avons un groupe assez important de bibliothèques / dépendances. Une idée de ce qui pourrait être faux? Si je contourne complètement les grades et tentez de compiler de la ligne de commande à l'aide de Javac et du pot de cheminement, je rencontre toujours le même problème.
Quel problème? Que le pot de cheminement ne fonctionne pas ou que certains sentiers de classe sont trop longs? Peut-être des chemins absolus dans l'attribut de classe-chemin fonctionnent sur certaines plates-formes mais pas sur les autres. Je l'ai testé sur Mac OS X.
Une autre façon de s'attaquer à ce problème serait de raccourcir le chemin de la classe en substituant des pièces de chemin commun avec une variable d'environnement (disedile_user_home).
Je vais admettre que j'ai seulement testé cela sur Windows. En fait, je n'ai besoin que de la tester sous Windows, car Windows est la raison de l'utilisation d'un pot de cheminement en premier lieu, en raison de la limite de taille unique de commande. En ce qui concerne la suggestion de variable env, j'ai envisagé cela, mais voir l'idée de JAR de cheminement aussi élégante. C'est un point de théâtre parce que l'idée de pavillon de cheminement ne semble pas fonctionner pour moi cependant. En attendant, nous avons une solution de contournement. Merci pour votre entrée sur ce Peter.
Les entrées de classe de classe sont toujours relatives Voir la spécification JAR: la valeur de cet attribut spécifie les URL relatives des extensions ou des bibliothèques selon laquelle cette application ou une extension a besoin [cité: docs.oracle.com/javase/1.4.2/docs/guide/jar/jar.html]
@Richardjohnson Mise à jour du lien pour un lien malformé / ancien dans le commentaire précédent: docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html
Si vous utilisez un démarrage à ressort et une graderie 4.x ou ultérieure, et essayez de démarrer l'application avec la tâche boodrun, la configuration doit alors être "RunTimeclassPath".
J'ai enfin obtenu l'idée "Pathing Jar" pour travailler. Je considère que ceci soit une solution de contournement permanente. Cela pourrait être considéré comme une solution si elle fait partie de la gradle elle-même.
Le code de jar de chemin d'origine a été fourni par Peter, mais cela n'a pas fonctionné. Le problème: les éléments de classePath référencés dans le pot de cheminement doivent être relatifs à l'emplacement du pot de cheminement. Donc, cela semble fonctionner pour moi. P>
Mais cela ne semble pas contenir le fichier JAR actuellement du projet dans la classe de classe?
Ce N'a pas fonctionné dans les versions Groovy entre 3.0.5 in 3.0.8 . Le problème de Grails liés comprend également une solution de contournement complète, en utilisant cette approche.
Je suis nouveau à la nivelle, mais quand j'ai essayé cette solution, elle s'est plainte de la graderie et de relativeclasspathentries non définies, j'ai donc ajouté une déclaration def dans chaque ligne.
C'est ce qui m'a aidé: P>
"Le nom de fichier ou extension est une erreur trop longue "à l'aide de gradle p>
En d'autres termes: Utilisez le plug-in com.github.ManifestClassPath. P>
Les autres solutions ne fonctionnaient pas pour moi, car la classe principale du projet réelle a finalement été incluse dans la classe de classe au moment de l'exécution. P>