Cédric Brun a écrit 74 commentaires

Notez qu'une alternative libre plus que convaincante existe : Mattermost.
Les intégrations sont "slack compatible" et il est très facile de réaliser des intégrations ad-hoc.

On a récemment déployé une instance de test pour la communauté Eclipse.

Juste pour signifie que côté Eclipse on est très content que Nuxeo décide de participer activement et de contribuer ECR en tant que "runtime".

http://ianskerrett.wordpress.com/2011/02/09/two-reasons-why-(...)

Et hop, quelques francophones de plus pour EclipseCon !

Oui il est possible ensuite de re-synchroniser des branches tout en définissant des politiques de fusion spécifique pour gérer les cas de conflit (ou un mécanisme interactif).

En fait c'est une erreur assez commune de penser que CDO est basé sur une BD, ce n'est pas le cas du point de vue de CDO. CDO utilise un "backend" pour stocker des données qui n'a en aucune façon besoin de gérer la concurrence ou les transactions (gérées par CDO directement). Les backends communs utilisent derrière une base de donnée (Relationnelle ou Objet) d'où la confusion.

CDO supporte le verrouillage d'éléments de modèles au grain le plus fin possible mais à l'heure actuelle ne "notifie" pas les clients lorsqu'un élément devient verrouillé.

Pour ce qui est des modeleurs, CDO est relativement transparent vis à vis de EMF Core, mais pour tout le reste non ce n'est pas aussi simple. La compatibilité avec GMF par exemple est un vrai challenge car elle nécessite de faire travailler de concert deux modèles de transactions différents (celui de CDO et celui de EMF Transaction).

CDO dans sa version 3.0 (sortie en Juin) permet la création de branches ainsi que l'utilisation en Offline avec une conception très proche de GIT :)

Effectivement, Digikam permet de stocker toutes les infos dans les meta-données des images qui sont réutilisées ensuite par les autres logiciels (testé sur une appli Apple ..)

En fait Eclipse - la platforme et Equinox - le runtime sont plutôt légers, c'est les plugins qu'on ajoute qui peuvent ralentir le tout si ils ne font pas particulièrement attention. Un google summer of code a été proposé cette année pour faire un "bootchart" du démarrage d'Eclipse mais il n'est malheureusement pas passé :/

Construire une distro dédiée à cette légèreté pourrait être un projet intéressant, c'est une critique que l'on entend régulièrement...

Pourtant dans Classic y'a tous les SDK de la plateforme, si tu ne développes pas de plugins Eclipse c'est typiquement des trucs qui ne te serviront à rien. Autant partir de la platforme directement : http://download.eclipse.org/eclipse/downloads/

J'en ai quelques un sous la main,

Acceleo :
http://wiki.eclipse.org/Acceleo/New_And_Noteworthy#Acceleo_3(...)

ATL :
http://wiki.eclipse.org/ATL_3.1.0_New_and_Noteworthy

EMF :
http://wiki.eclipse.org/EMF/New_and_Noteworthy/Helios

Les mainteneurs de "Classic" (l'équipe platform) n'a pas souhaitée l'intégrer. Globalement il est très intéressant de partir du bundle le plus proche de son domaine, "Classic" reste là pour des raisons historiques ;)

Hello :)

Généralement on utilise Wink, c'est pas parfait mais ça fait le job...

Pour ce qui est syntaxe textuelle, Xtext s'intègre parfaitement avec nos technos et fournit vraiment beaucoup de choses :

http://www.eclipse.org/xtext

Dernier exemple en date : protocol buffers

http://blog.efftinge.de/2010/04/googles-protocol-buffers-imp(...)

Cette fonctionnalité existe mais dans un composant commercial complémentaire : Obeo Pro Traceability (une fonctionnalité parmis beaucoup d'autres)

http://www.obeo.fr/pages/obeo-traceability

Il y'a un certain nombre de démos pour se faire une idée. Ce n'est cependant pas encore la panacée et il reste du travail pour gérer tous les cas possibles. Côté stage on est plein mais l'année prochaine, qui sait ;)

Pour ce qui est des attaques personnelles je t'invites à te renseigner un petit peu avant ce genre de commentaires, ça t'évitera de te sentir penaud par la suite.

J'ai entendu des milliers de fois ton refrain un projet bien fait est modélisé dès le début

Je dis tout à fait le contraire mais apparemment tu entends ce que tu veux, cet outil te permet justement d'itérer et de remettre en cause le modèle en permanence, c'est tout l'intérêt. Personne ici ne dit que c'est *la* solution mais c'est utile. D'ailleurs on est toute une boite (Obeo) à mettre en oeuvre ces solutions chez des clients et le moins qu'on puisse dire c'est que le retour est très positif, surtout de la part des développeurs justement...


Pour info Acceleo a été créé justement sur la base des retours concernant d'autres outils, il est probable qu'il s'agisse d'un de ceux là...

Votre truc de métatruc ça sera très bien quand ça sera bijectif, pas avant, fou toi le dans le crane.

Et bien non toujours pas, la bijectivité implique que l'on a autant d'informations dans le modèle que dans le code, de mon côté j'aime autant développer directement dans ce cas.

Pour info j'ai les deux technologies à ma dispositions (Obeo édite une solution bijective) et pour autant au sein de mon équipe on utilise Acceleo car ça correspond bien mieux à nos contraintes.

Dans tous les cas je t'invite à essayer, peut être que tu trouvera alors des arguments plus constructifs que mais tu n'y connais rien ou ça marche pas et puis c'est tout

En fait l'expérience montre que quand on commence à désirer ce genre de fonctionnalité c'est que l'on prend une mauvaise direction.

La génération est intéressante si à partir d'un élément modélisé tout un ensemble de choses sont générées : fichiers de paramétrages, doc, code avec API/implémentation. A partir de là on gagne vraiment en efficacité. Il est assez facile de voir que si on l'utilise ainsi (1 élément dans le modèle donne n éléments dans le code source) on ne souhaite pas et surtout on ne *peux* pas faire le chemin inverse dans beaucoup de cas.

bien qu'inutilisable en pratique il y'a de nombreux utilisateurs comme peuvent en témoigner le forum et les newsgroup Eclipse ;)

Après tout c'est un logiciel libre, il ne faut surtout pas hésiter à le rendre plus utilisable pour vos cas d'utilisation.

Acceleo supporte les itérations et le code manuel, on peut générer, faire des modifications, re-générer et les modifs ne seront pas perdues.

Ahhhhhhhhhh UML... Mais heureusement UML n'a que peu de choses à voir avec les modèles, il s'agit d'un cas précis particulièrement complexe.

Une petite présentation assez intéressante sur les légendes autour de modeling :
The Unbearable Stupidity of Modeling : http://www.slideshare.net/merks/the-unbearable-stupidity-of-(...)

Oui on a de nombreux exemples, tant dans des domaines plus embarqués (en C) que sur du JEE et des applications d'entreprises.

D'ailleurs quand on passe un peu dans les entreprise c'est plutôt rare quand une SSII ou un grand compte n'utilise pas déjà ces approches (a plus ou moins grande échelle), en tout cas je n'en ai pas croisé.

Quand on regarde d'un peu plus près on se rend compte :
- qu' Acceleo n'est qu'un outil générique qui permet de définir ses templates. On peut écrire des templates qui génèrent 100% du code ou bien des templates qui n'en génèrent qu'une partie comme dans le screencast (ça va dépendre du contexte d'utilisation)

- que si on est allergique aux boiboites ou si le formalisme choisi s'y prête moyen on peut définir sa syntaxe textuelle avec Xtext, (http://www.eclipse.org/xtext ) Acceleo s'en moque, pour lui c'est un modèle.

- que l'on choisi le niveau d'abstraction que l'on veut, on peut être très haut niveau ou très technique, voir les deux (exemple WISSS qui définit un formalisme pour les webapps, haut niveau pour le côté métier mais très précis et détaillé pour la gestion des droits).

- que c'est un outil parmi d'autres aidant à l'industrialisation, avoir un bel outil n'implique ni que l'on sache bien s'en servir ni que le problème s'est résolu par magie.

Je ne peux que plussoyer l'utilisation d'Acceleo, tu peux écrire tes propres templates et du coup générer exactement ce que tu veux.

De plus bien qu'Acceleo soit intégré à Eclipse tu peux l'utiliser en dehors en mode standalone et te faire ton petit générateur que tu appelle en shell voir que tu intègre à ton Makefile.

ps : je fais partie de l'équipe qui développe Acceleo :D

La difficulté de traiter ces problèmes tient principalement de l'hétérogénéité de l'ensemble. Concretement, Eclipse, la plateforme, c'est ridiculement petit, mais l'IDE Java, ou PHP, ou encore le bundle modeling, c'est des centaines de plugins qui collaborent : la cohérence technique est difficile à obtenir.

Pour donner un ordre de grandeur, Galileo c'est 24 Millions de lignes de code Java!

Un certain nombre de "bonnes pratiques" sont définies au sein du projet Eclipse pour éviter les problèmes de "temps de chargements" ou de "consommation mémoire", mais il est difficile de faire appliquer cela à cette multitude de projets.

Eclipse en lui même, par le biais d'OSGi, garanti qu'un plugin ne sera chargé que "lorsque l'utilisateur en aura besoin". Ainsi par exemple le premier démarrage d'un éditeur UML2 sera beaucoup plus long (les plugins se chargent). Malheureusement, bien que la plateforme permette en théorie de "décharger les plugins", la plupart des plugins partent de l'apriori qu'une chose chargée à un moment N, est toujours accessible à un moment N+1. Ce qui fait que généraliser le comportement du "déchargement" créerai beaucoup d'anomalie vis à vis des centaines de plugins, même externes à Eclipse.

Le conseil d'architecture d'Eclipse (Architecture Council - dont je fais partie) existe justement pour définir ces bonnes pratiques et les promouvoir.

Ne perdez pas espoir, Eclipse 4 est l'occasion d'être un peu plus strict à ce niveau là ;)

C'est bien subversive qui est inclu de base.

Superbe, tous les ans je m'essaye aux logiciels de montage grand public pour linux, et je n'arrive jamais bien loin. Le dernier essai en date de KDEnlive (7.X) était même assez catastrophique puisque ça a finit en segfault dès le démarrage.

Ici, rien à dire, ça démarre, l'interface, bien qu'encore un poil complexe, reste facile a appréhender et en quelques clics j'ai réussi à faire un petit montage et à exporter une vidéo du résultat.

Bravo à l'équipe et continuez comme ça !

Tu y ajoutes le plugin VI pour Eclipse et ça devient la méga-classe ;) !