Et c’est un problème pour moi : en Python, je n’ai pas besoin de toucher à mon PYTHONPATH, ma distrib le fait pour moi. En C, je n’ai pas besoin de toucher à mon LD_LIBRARY_PATH, ma distrib le fait pour moi. Par contre, en Java, non seulement le classpath n’est pas défini par la distrib, mais il est en plus spécifique à : mon package, la version de la lib installée (je met à jour fubar-1.2.3.jar en fubar-1.2.4.jar ? je dois mettre à jour le classpath de tous mes projets qui utilisent fubar). D’où mon scepticisme sur la possibilité de se passer de systèmes de gestion que je trouve pénibles genre maven.
Maintenant si tu prends comme exemple un hello world, je me demande bien quelle idée tu as eu de sortir Maven alors qu'un cp suffit
J’ai suivi un des premiers tutoriels mis en avant pour lift. Je lis rarement les docs spécifiques AVANT d’avoir suivi le tutoriel générique…
mais ça répond à un vrai besoin
Je n’ai vu aucun tutoriel Ruby on Rails qui me demande de prendre en main un truc genre Maven
Je n’ai vu aucun tutoriel Django qui me demande de prendre en main un truc genre Maven
Je n’ai vu aucun tutoriel web.go qui me demande de prendre en main un truc genre Maven
Je n’ai vu aucun tutoriel node.js qui me demande de prendre en main un truc genre Maven
Je n’ai vu aucun tutoriel Symfony qui me demande de prendre en main un truc genre Maven
Par contre, le premier tutoriel lift sur lequel je tombe, je me mange du Maven. Soit je n’ai pas de chance (ça arrive hein : ma première approche avec Gentoo, ça a été quand les dépôts officiels étaient cassés. Forcément, après ça, j’ai eu une très mauvaise première impression de la distrib, alors qu’après utilisation, si les dépôts sont cassés deux jours par an, c’est un grand max…), je suis tombé sur un tutoriel mal fait (mais pourquoi était-il mis en avant dans ce cas ? j’ai pas été chercher sur un site obscur, mais sur le site officiel…), soit Maven est une quasi-nécessité en Java (comme make et assimilés en C : tu peux toujours faire à la main, bien sûr, mais ce n’est clairement pas la méthode conseillée). Quand je dis : « j’aime pas scala parce que j’aime pas Maven », ça veut pas dire que je suis prêt à faire le boulot de Maven à coups de script bash, ça veut dire que je ne veux pas que toute la machinerie gérée par Maven soit un étape obligatoire pour pouvoir utiliser le langage (et utiliser au delà du hello world, hein ;)). Que maven soit possible, soit utile pour certains, évidemment que je n’ai aucun problème avec ça.
Pourquoi cherches-tu des excuses ?
Je ne cherche pas d’excuse. J’explique pourquoi j’ai éliminé scala de ma liste des possibles : parce que le premier tutoriel m’a fait bouffer trop de maven à mon goût, et parce que mes connaissances de l’environnement de dev Java me fait fortement suspecter que faire un projet Java sans Maven, c’est comme faire un projet en C sans make : une horreur encore pire que le mal (et comme, dans le cas de maven, je n’ai déjà pas le dit mal…)
Maintenant, les questions du genre « je veux de l’hibernate, c’est toujours aussi simple sans maven ? », elles ne sont pas rhétoriques : rom1dep m’a montré que j’avais tort sur l’obligation de maven pour le « hello world ». Il est possible qu’avec sa suggestion « Play! », il s’avère que j’aie aussi tort pour du HTTP. Si j’ai franchement tort pour toute lib externe que je pourrai avoir, crois-moi que je serai heureux : Go ne m’a toujours pas convaincu pour le web (beaucoup trop de perte d’expressivité relativement à rails ou même PHP à mon goût), et si ce qui me bloque l’utilisation de scala dans ce domaine (nommément : maven) est une erreur d’appréciation de ma part, crois bien que j’en serai le premier ravi.
[^] # Re: Intérêt
Posté par Moonz . En réponse à la dépêche Sortie d'une première version stable de Go. Évalué à 2. Dernière modification le 11 avril 2012 à 10:46.
Et c’est un problème pour moi : en Python, je n’ai pas besoin de toucher à mon PYTHONPATH, ma distrib le fait pour moi. En C, je n’ai pas besoin de toucher à mon LD_LIBRARY_PATH, ma distrib le fait pour moi. Par contre, en Java, non seulement le classpath n’est pas défini par la distrib, mais il est en plus spécifique à : mon package, la version de la lib installée (je met à jour fubar-1.2.3.jar en fubar-1.2.4.jar ? je dois mettre à jour le classpath de tous mes projets qui utilisent fubar). D’où mon scepticisme sur la possibilité de se passer de systèmes de gestion que je trouve pénibles genre maven.
J’ai suivi un des premiers tutoriels mis en avant pour lift. Je lis rarement les docs spécifiques AVANT d’avoir suivi le tutoriel générique…
Je n’ai vu aucun tutoriel Ruby on Rails qui me demande de prendre en main un truc genre Maven
Je n’ai vu aucun tutoriel Django qui me demande de prendre en main un truc genre Maven
Je n’ai vu aucun tutoriel web.go qui me demande de prendre en main un truc genre Maven
Je n’ai vu aucun tutoriel node.js qui me demande de prendre en main un truc genre Maven
Je n’ai vu aucun tutoriel Symfony qui me demande de prendre en main un truc genre Maven
Par contre, le premier tutoriel lift sur lequel je tombe, je me mange du Maven. Soit je n’ai pas de chance (ça arrive hein : ma première approche avec Gentoo, ça a été quand les dépôts officiels étaient cassés. Forcément, après ça, j’ai eu une très mauvaise première impression de la distrib, alors qu’après utilisation, si les dépôts sont cassés deux jours par an, c’est un grand max…), je suis tombé sur un tutoriel mal fait (mais pourquoi était-il mis en avant dans ce cas ? j’ai pas été chercher sur un site obscur, mais sur le site officiel…), soit Maven est une quasi-nécessité en Java (comme make et assimilés en C : tu peux toujours faire à la main, bien sûr, mais ce n’est clairement pas la méthode conseillée). Quand je dis : « j’aime pas scala parce que j’aime pas Maven », ça veut pas dire que je suis prêt à faire le boulot de Maven à coups de script bash, ça veut dire que je ne veux pas que toute la machinerie gérée par Maven soit un étape obligatoire pour pouvoir utiliser le langage (et utiliser au delà du hello world, hein ;)). Que maven soit possible, soit utile pour certains, évidemment que je n’ai aucun problème avec ça.
Je ne cherche pas d’excuse. J’explique pourquoi j’ai éliminé scala de ma liste des possibles : parce que le premier tutoriel m’a fait bouffer trop de maven à mon goût, et parce que mes connaissances de l’environnement de dev Java me fait fortement suspecter que faire un projet Java sans Maven, c’est comme faire un projet en C sans make : une horreur encore pire que le mal (et comme, dans le cas de maven, je n’ai déjà pas le dit mal…)
Maintenant, les questions du genre « je veux de l’hibernate, c’est toujours aussi simple sans maven ? », elles ne sont pas rhétoriques : rom1dep m’a montré que j’avais tort sur l’obligation de maven pour le « hello world ». Il est possible qu’avec sa suggestion « Play! », il s’avère que j’aie aussi tort pour du HTTP. Si j’ai franchement tort pour toute lib externe que je pourrai avoir, crois-moi que je serai heureux : Go ne m’a toujours pas convaincu pour le web (beaucoup trop de perte d’expressivité relativement à rails ou même PHP à mon goût), et si ce qui me bloque l’utilisation de scala dans ce domaine (nommément : maven) est une erreur d’appréciation de ma part, crois bien que j’en serai le premier ravi.