Reprise du message précédent :

quoi

feur

hihi

mouhais...
 
je viens de tester sur un hello world...mais ca aurait été pareil sur mon projet (mis à part que j'aurais 3 jars non dispo sur le net à foutre en plus, et un paquet d'images)
....
 
--> g plus aucun controle sur le build
--> le site généré est super sympa...
--> je vois toujours pas en quoi ca structure le projet...mis à part qu'un build prend 3 plombes, je vois pas l'intéret pour un petit projet...après c sur que le coup des dépendances automatiques, c surement très pratique pour un gros projet...mais le mien utilise que des libs standards java, ou alors des applis internes dans des jar, ou alors des ressources genre images, etc... ou alors des bouts de code non dispos en jar...

Tip pour Jubijub: peut être bien qu'utiliser maven te permettrait de travailler proprement dans ce cas (i.e. avec une structure standardisée au lieu d'avoir 36.000 bordels différent)

faut bien que je les stock qq part tt ce bordel non ?
 
Donc en quoi c mieux de le stocker n'importe où et de le dire à maven qui va me le rassembler dans un arborescence propre que de le mettre directement dans une arborescence propre ???
 
Concrètement je vois pas l'intéret, et je trouve que je perds totalement en maitrise sur mon build...je peux plus spécifier les tasks que je veux, les reps de sortie que je veux (c surement le but mais perso je trouve que ca me génère un bordel pas croyable (un truc qui devrait avoir 2 reps (src et build) fini par en avoir 7 + 7 fichiers à la racine, dont des fichiers XML dont je sais même pas à quoi ils servent)...
 
pour la doc je trouve ca génial : le site est super chouette, contient plein d'infos...(dont une grosse partie dont g rien à foutre, faut le dire aussi...le code metrics c bien mais bon...)
 
bref, je pense que c très bien pour un gros projet, dont la majeur partie des libs de dépendance sont des trucs du projet jakarta, ou dispo sur le web...ca implique aussi que tu bosses avec CVS ce qui est pas forcément le cas...je trouve qu'on perd la souplesse de ant, et ca bloate complètement les petits projets...
 
j'ai peut etre tort, mais je viens de l'essayer, et je suis totalement pas convaincu...en plus ca prend plus de temps de faire le project descriptor que de faire une arborescence propre et de copier les fichiers dedans...
 
pour avoir tourné un peu sur des forums, je suis loin d'etre le seul à penser ça...y'a plein de gens qui trouvent que ca bloate ant, et que finalement on peut très bien faire sans...

impression après 20 minutes d'utilisation, c'est un peu court jeune homme
 
-> Oui te "forcer" a avoir une structure standard est justement le but. Une fois que tu as standardisé ta manière de structurer ton projet, tu peux utiliser des tas de trucs de maven sans meme y penser (et ton projet aura dès lors une bonne structure)
 
-> Le target tu ne dois justement pas t'en préoccuper. T'as plus besoin d'aller voir ce qui s'y fait!
 
-> Tu peux définir des tasks sans problème dans le maven.xml en utilisant jelly
 
-> Si ton projet a des besoins qui rentrent dans les trucs supportés par les plugins, c'est clairement une techno à considérer je trouve. Par contre si tu fais plein de bordel custom à la con, ça sera probablement plus dur pour t'adapter à un truc standardisé (mais encore une fois c'est un avantage).

et vot' maven là, il me génère mon buldle mac OS X ?

il a dit du mal de Maven. Ca va trancher /o\

 
pas que je sache, y a un support pour nullsoft installer et rpm. Mais bon rien ne t'empeche d'écrire un plugin  

bah non, maven c'est une grosse daube.

oui c'est court...pourtant il m'a fallu moins de 5min pour baver devant les possiblités de Ant...
 
--> justement c quoi le tas de trucs ? parce que même en ayant lu tt le site (ce qui prend pas longtemps), j'ai rien trouvé d'autre que :  
- imports automatiques
- génération du site
- check out auto des sources depuis un CVS (et CVS seulement visiblement)
- génération auto de la doc
- build auto  
 
Les 3 derniers je les fais via Ant, sauf que avec Ant je suis pas limité à CVS...et je peux, en m'organisant bien, faire un build.xml totalement réutilisable...ce qui est d'ailleurs le cas du mien (qui me sert à l'heure actuelle sur 6 projets)...
 
et sur les 2 premiers trucs, le premier est génial mais me sert à rien perso (je dépends d'aucunes libs non dispo dans l'install java de base), et le second non plus en fait même si là l'intéret est grand je trouve...d'ailleurs g pas compris comment lui spécifier ses propres ressources
 
--> ca a l'air aussi pas mal orienté J2EE d'après la liste de plugins...
 
-->la partie intéressante de la doc c ca : http://maven.apache.org/reference/dirlayout.html et c'est pas tellement différent de mon layout standard généré par Eclipse...
 
en gros Maven c une abstraction d'outils dont Ant qui est lui même une abstraction du processus de build...le hic c que je trouve que ca fait bcp d'abstraction, et que finalement ca cache la merde au chat, et que si tu veux modifier un truc faut remuer la merde...et apprendre par là même le super language de script jelly...
 
http://www-igm.univ-mlv.fr/~dr/XPO [...] /home.html
 
Je suis pas forcément d'accord : un bon build.xml est un build.xml réutilisable...ca se base d'ailleurs totalement sur la philo de maven de partir avec une arbo de sources unifiée...

ça vous parraît raisonnable d'appeller Thread.suspend() dans un profiler (sur les taches à analyser) ?
 
ça me parrait pas trop grave perso.

http://cvs.sourceforge.net/viewcvs [...] &view=auto
exercice : brancher le support mac os X sur ce tas de merde ...

vous arrivez à baver devant Ant ?    
je l'utilise mais je le trouve parfois lourdingue

stadire?

c une logique à prendre, mais je trouve ca hyper pratique...et  ca a l'air de se préter à des trucs marrant, genre le rempalcement dynamique de classes, etc...et si tu te forces à mettre tes projets dans une structure cohérente, un build ant devient très réutilisable...

darklord> c'est toujours sur un fond d'une vieille discuss que l'on avait eu
 
je devais lancer l'exécution d'une classe avec un file ou un dir, dans le cas du file c'était ok, impossible de le faire pour le dir car ant de permet pas d'itérer sur les file d'un dir.
 
bref, ça fait un moment maintenant sans doute qu'ils ont corrigé leur brol. j'avais d'autre reproches mais pas sous le coude là de suite.
 
edit: je me souviens d'un truc vachement bien: les valeurs de retour d'une exécution (par exemple) pas moyen de savoir si un truc s'est bien passé si ce n'est en lisant sois même la console (mais là j'attends les réponses des pros de Ant car ça m'intéresse toujours, je m'y suis p-ê pris comme un manche).
 
donc j'ai codé mon m'tit ant à moi qui va bien juste pour le fun et il s'appelle cicada (edit: gestion des file/dir, retours de valeurs, ...)
(il ne fait pas grand'chose mais c'est juste pour me prouver qu'il faut pas être un ingénieur avec 10 ans d'xp pour ne pas oublier de faire certaines choses de base je rigoleuh... j'utilise Ant régulièrement pour des compils et mises en prod')

 
C'est juste. Pour ton problème d'exec c'est fixé depuis ant 1.6
 

 
http://ant.apache.org/manual/CoreTasks/exec.html

enfin. cool

Question sur le pattern Visitor :  
 
le patterne visitor c'est cool, mais comment ca se passe quand tu as une hierarchie d'objets à visiter un peu grosse ?  
 
Je m'explique :  
 
Ca c'est le cas d'école : (écrit en abrégé)
 

 
maintenant, quand on a des sous classes pour les classe à visiter :  

 
le visitor va avoir la forme :  

 
Si je veux faire un VisitorAdapter (classe de facilitation pour les futur class d'implémentation de visitor). A votre avis il vaut mieux qu'il soit comme ca :  

ou comme ca :  

 
la 2e solution me parait plus avantageuse : si on veut surcharger le comportement du visitor pour A, ca surcharge en même temps pour tous ses dscendants. Mais est ce que c'est pas trop inhabituel o uestce que ca cache pas des problèmes que je ne vois pas ?
 
merci à ceux qui ont lu jusque là
 
nraynaud  ?

tu me résumes en 5 lignes l'intéret de ce DP ?

pouvoir traiter de manière similaire des objets qui à la base n'ont pas une interface commune.
 
pour info, tous les dp du gang of four se trouvent sur le web, enfin je crois. et achète le bouquin, si tu dois n'en acheter qu'un c'est celui là. (à condition que tu arraches les pages concernant le singleton)

déjà abordé ici ou dans d'autres topics ...
en gros, ca évite de faire des moches  
if (o instanceof A) {
  ...
} else if (o instanceof B) {
  ...
} else ...

 
pkoi ca s'explique le singleton ??? (pis c le seul DP que je connaisse, me le vire pas )
 
--> g une classe qui gère 3 listes qui ne doivent exister qu'une fois dans l'appli...pour des raisons de synchronisation, la classe qui gère les listes ne doit elle aussi exister qu'une fois
si ca je dois pas le mettre en singleton je fais comment ?

vu que je compte chercher un bouquin là-dessus justement, qu'y a-t-il de particulier avec cette partie singleton ?

je viens de lire un truc...en gros tu peux "décorer" que l'appel à une interface quelconque d'un objet ?
 
==> ca oblige donc à penser que l'objet décorable doit avoir ladite interface, que donc il faut penser à implémenter icelle dès le départ en fait...
 
comme je voyais ca au début, je pensais que t'avais un truc existant, et que tu utilisais un décorateur pour le custom...mais en fait c pas possible si le truc existant a pas l'interface qui fait ce que tu veux

 
je crois qu'il aime pas ce truc parce que c utilisé à tort et à travers et que ca peut foutre le bordel mal employé...g bon ?

Et ma question ?

y'a rien, elle explique très bien ce qu'est le singleton, mais le singleton cai moche et dépassé.

euh t'as du mal lire ou lire le mauvais truc parce que le visiteur c'est précisement pour - comme je viens de le dire - pouvoir traiter de maniere similaire des objets qui ne le sont pas

http://www.exciton.cs.rice.edu/Jav [...] attern.htm

me parait pas clair.
procure le bouquin (si impossible, pm) de Gamma et al. (aka le Gang Of Four), la bible quoi.

au risque donc de paraître has-been, j'utilise les singletons dans mes projets, c'est propre et ça marche bien...
 
en quoi c'est moche ?
 
pour le côté dépassé, cela voudrait laisser penser que ce "fameux" Gang of Four n'est pas si fameux puisque ce DP est dépassé... (je charie )

euh en meme temps, ça fait 10 ans que le bouquin à été écrit, et puis dépassé, seulement pour une certaine élite
 
et puis vous faites chier à me reposer cette question à laquelle je n'ai pas de bonne réponse toute faite
http://www.google.be/search?q=singleton+antipattern

mouais, ils charient quand même...
(et on fait pas chier, on s'instruit. )

tu peux avoir des sous-Visiteurs,  
exemple bateau, grammaire des expressions :
Expression
 
UnaryOp extends Expression
BinaryOp extends Expression
Constant extends Expression
 
on a (en court-circuitant)

 
On a absolument pas spéculé sur l'implémentation des opérateurs encore, ça peut être un truc style

Auquel cas le Visiteur fonctionne, mais ça peut être une hiérarchie :

 
avec un sous-visiteur de BinOp :

 
en gros.

ok, c'est un autre solution. Je vois pas trop ce qu'elle apporte par rapport à un visiteur qui aurait les méthodes à executer pour tous les types et sous types (comme dans mon exemple). A part une certaine souplesse : on peut construire l'objet visiteur par imbrication => on a une granularité plus fine ... Tu vois d'autres intérêts ?
 
Dans mon cas, la granularité, je m'en tape un peu ... je trouve qu'un seul visteur qui fait tout est suffisant.
 
Je me demandais ce que tu (ou vous, mais les autres on l'air de s'en battre les glawoui) pensais de l'adapteur. Quelle forme tu préfères?

l'autre
 
encore faudrait-il vous suivre... (là je parle pour moi, pour les autres qui se battent les glawoui, je ne sais pas)