Je ne développe peut-être plus en java (encore une fois, ça m'est arrivé de le faire il n'y a pas si longtemps). Par contre, il m'arrive nettement plus souvent de devoir faire marcher du code java existant, et c'est parfois le drame. Quand on me fournit du code sous disant portable et qu'on me dit que si je veux le faire marcher chez moi, il faudra que je passe par Eclipse, je ne suis pas d'accord (et oui, cette situation arrive vraiment). Donc je m'obstine à devoir me passer d'Eclipse (c'est censé être portable bon sang) mais je me retrouve souvent face à des sourds, à essayer de comprendre comment me débrouiller avec ce Eclipse a pondu pour permettre la compilation, et comparé à un Makefile c'est vraiment le jour et la nuit. On sent tout de suite l'infériorité de la génération automatique par rapport à l'écriture d'un script par un humain. Alors oui, générer automatiquement c'est bien, dans l'absolu c'est l'idéal, dans la pratique ça semble très sexy aussi, mais il faut savoir placer la barre au bon endroit. Et avec Eclipse, la barre est bien au delà du raisonnable. Tu vas me redire que je perds mon temps à faire un Makefile par OS à chaque fois. Oui, c'est vrai... mais j'en perds moins que ceux qui passent leur vie à faire en sorte que la partie compilation de projets dans Eclipse marchent. Et puis, un Makefile bien fait, c'est grandement réutilisable.

Je peux comprendre que tu ne veilles pas sortir du santier battu tracé par ton enseignement et ton quotidien au travail (parce que tu n'as pas le droit, parce que tout le monde te le déconseille, parce que tu ne peux pas faute de temps/envie/compétences/ouverture d'esprit/autre), mais c'est dommage. ça en devient même dramatique quand je te vois dire que ce que c'est moi qui dit des énormités alors que tout ce que je dis au final, c'est qu'il faudrait revenir à des choses plus simples (en premier lieu en java, mais j'ai aussi ces abominables autotools en tête, qui sont le pendant pour le C/C++ avec lesquels je me bats encore plus souvent).

"Quand on me fournit du code sous disant portable et qu'on me dit que si je veux le faire marcher chez moi, il faudra que je passe par Eclipse"

-voila pourquoi utiliser ant ou mavan.
mais déjà on ne parle pas de la même chose, la clairement le truc : "tien mon code source copie le sous eclipse" ca sens le partage de code sources entre étudiants. et encore de petit projet...

"Oui, c'est vrai... mais j'en perds moins que ceux qui passent leur vie à faire en sorte que la partie compilation de projets dans Eclipse marchent"
-sauf que ton entreprise te paye toi et pas les mecs qui ont codé eclipse. donc en plus d avoir mis plus de temps a le faire tu fais un truc que seule toi sera motiver a relire ou a faire évoluer. les projet maven ca se déploie sur tout et n importe quoi. maven te suit de la compilation en passant par les test unitaire jusqu au déploiment final chez le ou les clients. et pour avoir parlé un peu avec un des employé de IBM france de saint nazaire responsable d'une des 3 branche d'éclipse, pour eux c'est le projet eclipse qui a sauvé java. Je ne sais pas si c'est vrai mais en tout cas il est clair que eclipse a grandement participé au succes de java et lui à permettre d'être la ou il est aujourd'hui. donc je ne pense pas qu il est l impression de perdre son temps.

pour moi chris a une vision très scolaire des choses.En gros : "je fait comme je veux je m en fiche si je met plus de temps, si personne d autre que moi ne comprends ce que j'écris et si c'est en total contradiction avec la philosophie du langage sur le quel je boss tant que a moi ca me plais."

ant ou maven est en une optique d'entreprise, de projets en équipe.
l insociable qui nous pond sont makefie de 8 pages dans son coin que lui seul arrive a comprendre et a modifier ça n'intéresse pas les entreprises.

godrik
"La derniere fois que j'avais regarder, ca ressemblait a une reecriture de make en java avec des "makefile" ecrit en xml. Mais ca n'avait pas l'air de faire plus ou moins de chose..."
-Ba oui ( c'est court ^^ ). c'est le remplacent de makefile pour java donc effectivement ça fait plus ou moins la même chose. en plus simple plus rapidement plus adapté au java et avec une indépendance de la plateforme et un tas de chose qui te facilite la vie.

maven a aussi de nombreux avantages. pour des projet atypique je préfère ant (avis personnel ) mais pour de gros projet ( de plusieurs années et donc plusieurs personnes qui risque même de former de multiple autre petit projet dont va dépendre le projet principal ) je préfère maven. plus dirigiste certes mais quand on commence de gros projet au final ca n'est pas plus mal que tout le monde aille dans le même sens dès le début.

Je viens de jetter un oeil.
mmm, je vois, yet-another-automatic-compilation-tools...
Ca devient lassant...

C'est assumé
ant "Another Neat Tool" ^^

l insociable qui nous pond sont makefie de 8 pages dans son coin que lui seul arrive a comprendre et a modifier ça n'intéresse pas les entreprises.

Zut, je n'intéresse pas les entreprises La globalisation ça va bien cinq minutes, hein.

Bon j'avais dit que je n'argumenterai pas pour éviter de relancer la machine acemicka et les « débats » sans fin mais là c'est trop agaçant.
En préambule tu accuses Chris_27 d'avoir un point de vue scolaire, or si on se fie à ta carte de visite tu es encore étudiant à la faculté de Nantes. C'est donc très rigolo de te voir prendre de haut quelqu'un sous un tel prétexte. Bref, passons…
Pour situer, après mes études (qui ont comporté deux stages longs — 2x6 mois) j'ai bossé un peu plus de deux ans en tant que développeur java/j2ee (sous un nom beaucoup plus sexy pour ne pas trop faire de mal à l'égo) dans trois boites différentes et maintenant je bosse depuis bientôt deux ans chez ce que l'on appelle un « client final » dans le domaine du spatial au sein d'un service de gestion de configuration/qualité des logiciels. Je ne dis pas ça pour me faire de la pub ou me permettre d'être condescendant mais seulement pour appuyer le fait que quand je dis que Eclipse, Ant et Maven (et on peut facilement étendre la liste, le framework spring remportant à l'aise la palme du logiciel le plus largement répandu et le plus aberrant qui soit) sont des cochonneries, je parle en connaissance de cause.
On va séparer de mes expériences professionnelles la première catégorie où je me positionnais en tant que développeur de logiciels (mes deux stages suivis de mes trois premières expériences) de la deuxième (mon emploi actuel).
Lorsque j'ai débuté le développement mon bagage académique n'était clairement pas adapté à la façon de travailler dans l'entreprise (pas de langue de bois, parlons de SSII). Grosso modo s'opposait à un enseignement théorique où on revient aux fondamentaux ou l'on n'utilise pas ce que l'on ne comprends pas, un monde « clefs en main » où il faut produire le plus vite possible, le plus de code possible, bien souvent très mauvais. Forcément en débutant, je ne me voyais pas utiliser autre chose que le cliquodrome magique sous peine de me taper des journées de boulot de quinze heures et de passer pour un barjot (ben oui les premiers temps, devenir non seulement opérationnel mais réellement productif n'est pas compatible avec l'adaptation d'un autre workflow de développement que celui « imposé » par la boîte). Dans ce premier job, j'ai côtoyé une population d'informaticiens très variée (ça allait du polytechnicien pas trop ambitieux au geek accro tout droit sorti d'une école de pure informatique en passant par le chimiste qui ne trouve rien dans sa branche ou le contrôleur de gestion qui cherche à se réorienter). À l'époque (2005/2006) c'était l'explosion de l'informatique, l'un des seuls secteurs qui embauchait à tour de bras à peu près n'importe qui en payant plutôt bien et une telle hétérogénéité de profils au sein d'une même SSII n'était pas rare. Dans ces cas-là, comment amener le plus rapidement possible, le plus de développeurs possible à un niveau suffisamment « honnête » pour vendre une prestation ? Et bien je vous le donne en mille Émile, il s'agit du nivellement par le bas. On fournit aux développeurs le plus de boîtes noires possibles (frameworks de développement et logiciels) et des procédures/check-lists adaptées.
« Pour faire un beau logiciel respectant le pattern MVC :
1— Copier/coller le squelette de projet fourni par machin
2— Coller les jars du framework bidule /là/où/il/doit/être
3— Lancer Eclipse
4— Créer une fichier de mapping xml en respectant la doc bidule pour coller à la BDD généré automatiquement par le générateur truc
5— Créer une classe contrôleur appelée fooControleur.java et collez le squelette de code fourni aussi par machin
6— /!\DANGER/!\ : il faut utiliser son cerveau ici !!! Dans les trous écrivez du code respectant la spec fournie »
7— Copier/coller le build.xml fourni par machin /là/où/il/doit/être puis cliquez sur le bouton générer dans Eclipse
8— Si tout s'est bien passé, cliquez sur le bouton Commit.
»

Je n'exagère presque pas. Alors, certains diront que c'est productif. Oui, on débite du code au kilomètre mais à aucun moment quelqu'un a réfléchi sur la solution qui irait le mieux, le choix le plus intelligent. Niet ! On code, on code, on code ! Alors oui le code est dégueulasse, oui il y a environ quinze fois plus de lignes de code que le même outil d'il y a quinze ans qui marchait très bien mais qui avait une trop sale gueule mais c'est pas grave, c'est productif ! C'est le monde de l'entreprise, c'est nous qui sommes dans le vrai !
Dans mes deux emplois qui ont suivi, j'ai commencé à être plus à l'aise et ai pu commencer à sortir des sentiers battus sans perdre en productivité (principalement dans le deuxième qui était un société éditrice de logiciels open source). Alors bien-sûr on m'imposait le framework spring/hibernate/whaterver de merde, l'outil de génération foireux mais je pouvais utiliser vim, divers scripts d'audit de code, débuguer en console. Le temps que je « perdais » sur la non insertion automatique de jar par Eclipse, je le gagnais sur le débugage et les gens qui bossaient comme moi étaient loin d'être les employés les moins productifs. Systématiquement, lorsque je perdais beaucoup de temps ça venait des boîtes noires, un xml mal parsé par spring, un mapping mal pris en compte par hibernate, un bug d'un plugin maven, etc. Alors ou dans le beau monde de l'entreprise™, on s'en fout, si ça merde on gagne la TMA ! Pareil côté client, un projet qui ne déconne pas est vu comme un projet facile et non comme un projet bien mené. Un bon vieux projet mal branlé qui prend du retard, rien de tel pour négocier une jolie augmentation. Ce n'est pas une blague. Cet aspect-là je le côtoie au quotidien dans mon boulot actuel. Tout le monde sait que ces technos sont merdiques mais tout le monde s'en satisfait. La SSII qui peut fournir très vite de la merde, le client qui soit comme je l'ai mentionné est « content » que tout ne soit pas rose soit, pour ne pas faire de vagues, fait comme tout le monde (Ajoute à ça que beaucoup de non informaticiens se retrouvent par le biais de mobilités internes à gérer des projets informatiques).
Maintenant, venons en au cœur des choses, le gros de mon boulot est de faire l'interface entre mon employeur et tous les industriels/SSII/éditeurs qui produisent des logiciels pour lui pour m'assurer qu'on est indépendant quant à la doc et à la génération. Grosso modo, on doit être capable dans vingt ans de regénérer un logiciel sans être un expert. Il faut donc s'assurer que le code est correct et que le processus de génération (doc et scripts si tu veux) soit suffisamment bien fait pour que n'importe qui réussisse à produire le logiciel en le suivant. Et toutes ces merdes java soit disant portables sont un vrai cauchemar. Ça passe par des gus qui nous livrent des applications tellement intrinsèquement liées à Eclipse (les applications RCP sont à la mode en ce moment) qu'on est obligé de lancer le bousin pour générer (sympa quand on travaille par ssh !), ou encore par le gland qui compte sur maven pour télécharger toutes les jars dont il a besoin sur le net alors que le produit sera généré sur un serveur sécurisé déconnecté du réseau. On pourra dire que tout ça est un problème de mauvaise utilisation de l'outil, c'est vrai mais ces derniers sont faits pour être mal utilisés par défaut. Deuxième gros problème de cette nouvelle vague java et l'explosion des dépendances, il n'est pas rare qu'on se trouve avec des tous petits projets qui embarquent des centaines de mégas de jar presque inutiles (merci les dépôts Maven…) souvent piochés n'importe où et sans garantie de pérennité. Super pour la maîtrise des logiciels… Les vieux routards de mon service sont éberlués par l'explosion de la taille des applis pour ne rien faire de plus que les ancêtres en C et en Fortran.

En bref, pour être passé aussi bien par la case fournisseur que par la case client, je hais viscéralement ces outils. Je reste convaincu qu'ils sont fait pour faire les choses salement et à la va vite. Tu noteras que je n'ai pas craché sur ant qui pour moi n'est rien de plus qu'un Makefile en xml beaucoup plus compliqué. L'aspect portabilité, laisse moi rire ! Dans ce que tu appelles la vrai vie, soit le monde de l'entreprise™, rien n'est portable. Les specs sont faites de telle sorte qu'un logiciel est fait pour un environnement et pas un autre (t'as même des contraintes sur la version du compilateur — « Ah non mon bon monsieur, mon logiciel est garanti jdk1.6.0_17, je ne peux rien pour vous si ça ne marche pas avec une jdk1.6.0_18 »). En plus la portabilité de java est une vaste blague. T'as déjà vu la tronche des machines virtuelles pour AIX ou HP-UX ? Dans les faits on ne perd pas plus d'argent à porter du C que du java.

Autre chose, sur ton poste perso combien utilises-tu d'applis java ? T'es-tu déjà posé la question de pourquoi dans le monde du travail 90% des applis sont développés en java alors que dans la sphère d'utilisation personnelle il y en a clairement moins de 10% ? Pourquoi les gens qui développent pour leur plaisir, qui ne sont pas contraints par la pression du rendement ne choisissent pas java ?

Ce que je dis fait argument d'autorité. J'en ai conscience mais toute ta pipotique théorique sur l'utilisation de ant soit disant mieux adapté qu'un makefile ou de maven qui est génial pour le déploiement chez le client ne vaut certainement pas mieux. Quant à ton contact d'IBM, s'il dit vrai, et bien le fondateur d'Eclipse aurait mieux fait d'aller à la pêche le jour où il l'a créé car pour avoir porté aux nues un langage aussi dégénéré que java, il mériterait la prison.

J'ai dit ce que j'avais à dire et n'en dirai davantage, car si réponse à ce message il fera nécessairement tourner le débat en guerre de chapelle et ça ne m'intéresse pas du tout.

« pour moi chris a une vision très scolaire des choses. » et toi une vision très locale d'ingénieur.

Si j'accepte de perdre du temps à soigner mon Makefile (qui dépasse rarement 50 lignes, même sur un gros projet) c'est parce que je sais que les gens qui voudront utiliser mon code vont gagner du temps en contre-partie. En échange, mes utilisateurs vont aussi développer du code simple que je pourrais utiliser sans perdre de temps. Bref, au final je m'y retrouve. Bien sûr, ceci se passe sur une échelle petite par rapport au monde de l'industrie, mais il n'y a pas de raison théorique qui empêche d'étendre le concept de privilégier la simplicité (aka KISS) au monde industriel.

Comme je l'ai déjà dit, avec ton approche tout en un Eclipse, il y a beaucoup de perte de temps en amon (chez ceux qui développent Eclipse) et en aval (c'est ceux qui doivent se battre parce que l'outil a montré ces limites). Bien sûr, tout bon ingénieur va me dire qu'on se fout de tout ce temps perdu, vu que c'est quelqu'un d'autre qui le perd… mais c'est de l'égoïsme pur et dur.

« -sauf que ton entreprise te paye toi et pas les mecs qui ont codé eclipse. » j'ai dit que j'étais bien d'accord sur le fait qu'on ne fait pas ce qu'on veut. Il n'empêche que … cf paragraphe précédént.

« "tien mon code source copie le sous eclipse" ca sens le partage de code sources entre étudiants. » si seulement… Linux marcherait bien mieux si ces problèmes stupides n'apparaissaient que dans les petits projets comme tu dis.
Après, je veux bien croire que le problème est plus fréquent dans le monde libre que dans l'industrie.

« l insociable qui nous pond sont makefie de 8 pages » l'inscoiable en question, c'est automake.

"En préambule tu accuses Chris_27 d'avoir un point de vue scolaire, or si on se fie à ta carte de visite tu es encore étudiant à la faculté de Nantes."

Regarde la date d'inscription de la carte de visite...dsl si mettre a jour mes données jeuxvideo.com n'ai pas dans mes priorités...

de plus on peut etre scolaire et avoir une vision d entreprise et inversement... il n'y a en plus pas trop de rapport entre la vsion des chose et l endroit ou tu es... enfin bref

Autre chose, sur ton poste perso combien utilises-tu d'applis java ? T'es-tu déjà posé la question de pourquoi dans le monde du travail 90% des applis sont développés en java alors que dans la sphère d'utilisation personnelle il y en a clairement moins de 10% ?

bcp. et pour l exemple d appli perso je pourrai te sité android. alors certes bcp d appli sont médiocres mais elle sont bien là.

après oui tu as bien argumenté ton avis cette fois^^. et on n'est d accord java et ses outils ont été fait pour faire du code vite. mais la ou je ne suis pas d accord c'est le code sale. ca ca dépend en grande partie de ceux qui ont décidé les grandes ligne du projet. et dans certaine boite qui sont plus dans une culture d entreprise tu es souvent convié au réunion et on te demande meme en combien de temps tu compte pouvoir faire ca ou ca et ce que tu penserai de tel ou tel choix. après la les défauts que tu énonces viennent plutot des SSII en elle meme plutot que du langage java.

java et ses outil ont été pensé et fait pour permettre aux développeur de se concentrer sur les vrai probleme algorithmique.