Re : [Tsp-devel] Sondage: utilisation d'Ant et Eclipse

[eric.noulard]

J'ai oublié de dire un truc hier.
Mon expérience est que c'est difficile de partager le fichier
projet Eclipse car chacun peut avoir une conf' eclipse assez différente
suivante suivant les plugins qu'il a installé et le fichier projet
contient (sauf erreur de ma part) des références au plugins
notamment via les balises <nature>.
Par exemple dans ma conf actuelle:
        <natures>
                <nature>org.eclipse.jem.workbench.JavaEMFNature</nature>
                <nature>org.eclipse.jdt.core.javanature</nature>
                <nature>com.omondo.uml.std.Nature</nature>
                <nature>org.eclipse.jem.beaninfo.BeanInfoNature</nature>
        </natures>

D'ailleurs à mon avis c'est une erreur, car le même projet ouvert avec  
un Eclipse contenant des plugins différents ne donnera pas le même .project...

---
Eric Noulard - Software Architect 
BT Consulting & Systems Integration
tel: (+33) (0)534 604970
web: www.bt.com/consulting



-------- Message d'origine--------
De: address@hidden de la part de Stephane Galles
Date: mar. 16/08/2005 23:16
À: tsp-devel
Objet : Re: [Tsp-devel] Sondage: utilisation d'Ant et Eclipse
 

Bonjour, bonjour, grosso modo nous avons 4 sujets :

1) Ant dans le monde JAVA

Coté JAVA, il n'y a aucune ambiguité, la bonne pratique actuelle est :

Il faut TOUJOURS avoir un build COMPLET avec Ant pour le projet.

2) Eclipse dans le monde JAVA

Pour l'IDE, on peut utiliser ce que l'on veut. L'idée générale
est qu'on aura toujours Ant sous la main, mais pas nécessairement
l'IDE qui avait été utilisé (c'est aussi un problème de pérénité).

Cela peut être sympa de fournir les fichiers de projet d'Eclipse.
Certains projets le font. Mais il faut voir cela comme un "nice to have",
car coté JAVA, c'est toujourd Ant le "vrai" moyen de
faire un build complet du projet (et j'inclu la compilation la dedans,
et tant pis si cela fait double emploi avec la compilation de l'IDE).

3) Ant dans le monde C/C++
Je ne sais pas du tout quel est le degrés de pénétration des build Ant
pour du C/C++, et je ne connais pas ou peu les extensions disponibles
pour faire cela.

C'est osé, mais pourquoi pas. Il va simplement falloir convaincre les purs
et durs du C/C++ qu'il peuvent lancer une JVM pour deployer leur projet
sans attraper la peste ou bien provoquer des pluies de sauterelles  :)

D'autre part, et c'est un peu hors sujet, mais quand il y besoin de 
faire des
choses un peu plus funky avec Ant, il est toujours possible de lui associer
des languages de script (exemple : 
http://www.pycs.net/users/0000177/stories/11.html ).
On a alors a disposition un peu ce que l'ont veut (Jython, Groovy, etc...)

4) Eclipse dans le monde C/C++

Coté C/C++ pour Eclipse, aucune idée, j'avais utilisé Eclipse pour cela 
mais il
y a fort longtemps, je ne sais pas quel est le degrés de maturation de 
l'IDE.

Voila, voila...



Eric NOULARD wrote:

>Salut à tous,
>
>Je viens avec un petit sondage en poche
>qui peut se résumer à:
>
>1) Que pensez-vous de généraliser/favoriser
>   l'utilisation d'Ant et d'Eclipse dans
>   l'architecture TSP?
>
>   1.a) favoriser/utiliser Ant
>   1.b) favoriser/utiliser Eclipse.
>
>En sachant que quand je dis favoriser/généraliser cela
>signifie utiliser Ant et/ou Eclipse y compris pour
>le développement en C, C++, perl, python...
>
>Je vous pose la question car j'ai ajouté à la partie
>C un build file ant qui permet de:
>
>       1) créer un zip / tar / tar.gz
>           propre de l'arbo C
>       2) créer les RPM sources et binaires sur l'hôte
>           de compil' si c'est un système qui dispose
>           de rpm/rpmbuild.
>
>Rien que les zip/tar/tar.gz sont tellement plus pénibles
>à faire avec un script et je dis ça en connaissance de cause
>vu que j'ai écris le script src/scripts/tarball qui
>tente de faire un tar.gz avec ce qu'il faut dedans mais
>pas plus (notamment pas de CVS/ de core [mais il faut bb_core* ...].
>
>Bref mon avis est (ça vaut pour tous les langages):
>
>1) Il faut favoriser l'utilisation de Ant pour toutes les tâches
>   automatisables qui ne soient pas de la compilation
>   (pour l'instant et sauf pour Java ou le couple Ant/Eclipse est 
>   obligatoire à mon sens)
>   Déploiement, lancement d'autotest, actions CVS éventuelles pour
>   la création de version.
>
>2) Il faudrait commencer à utiliser Eclipse y compris pour le C/C++
>   car c'est vraiment un environnement ouvert généraliste 
>   (?le seul aujourd'hui)?
>   D'ailleurs le projet:
>   Eclipse Test & Performance Tools Platform (TPTP)
>   http://www.eclipse.org/tptp/index.html
>   me parait une raison "suffisante" pour qu'Eclipse aille de pair
>   avec TSP.
>   De plus l'environnement de dev pour le C/C++ semble mature
>   (je ne peux pas être catégorique car je ne l'ai pas suffisamment
>    essayé).
>   http://www.eclipse.org/cdt/
>
>Reste 2 points noirs en ce qui me concerne vis-à-vis d'Eclipse.
>
>1) En dessous de 512 Mo de RAM et une machine pas trop vieille
>   vaut mieux pas essayer
>   (avec quelques plugins en dessous de 1Go c'est vite intolérable)
>
>2) Il faut une JVM pour l'exécuter quoique visiblement une
>   exécution NATIVE est désormais possible via / gcj/gij
>   http://klomp.org/mark/gij_eclipse/
>   http://www.linuxjournal.com/article/7413
>   Je n'ai pas testé.
>
>
>Quoiqu'il en soit si nous voulons que TSP reste 
>(hum cet avis n'engage que moi, certains diront peut-être devienne?) 
>un projet à la pointe de la technologie, une bonne pépinière
>d'idée technique ainsi qu'un projet crédible industriellement
>je pense qu'il ne faut pas rater le virage Eclipse/(et Ant vient avec).
>
>Votre avis?
>
>
>Eric
>
>
>
>_______________________________________________
>Tsp-devel mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/tsp-devel
>
>
>  
>



_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel