El Titi a écrit 3953 commentaires

Il tourne très bien sous windows sans vm

Excellente remarque !

La dernière version propose enfin la gestion de compte à débit différé.
Est-ce la 0.6.9 ?

Si je saisis bien le fonctionnement de cet outil pour la gestion des tickets:
Lorsque l'on contribue à un projet en le "forkant", on pushe vers le dépôt de référence et c'est une convention de nommage qui permet d'isoler chaque contributeur, là où le fork de Github crée un clone à la volée sur le serveur.
Ensuite pour l'acceptation, l'intégrateur se contente de merger cette branche en local et de pusher sur la branche d référence.
Le dépôt de référence est donc suceptible d'être pollué par d'autres branches ce qui va à l'encontre de la philosophie du "pull request".

Pour ce qui est des fonctionnalité, hormis l'interface de gestion de ticket je préfère nettement SCM Manager
( http://www.scm-manager.org/ ) qui est très comparable en terme de fonctionnalité pour un gestionnaire de dépôt (full Java, integration LDAP, …)

Nous l'utilisons depuis 1 an et demi dans notre entreprise (une DSI). Il héberge plus de 800 dépôts et s'intègre très bien avec le reste de notre forge basée sur la suite Atlassian (JIRA/Bamboo/Crowd). Un plugin d'intégration à Crowd est fourni (annuaire Atlassian qui lui même référence l'annuaire AD de l'entreprise).
Il est maintenant très stable et supporte par ailleurs les pull request à la manière de Github et donc de façon cloisonnée.

Le seul inconvénient.
Dans JIRA les commits d'un ticket sont référencés dans l'onglet description alors que SCM Manager ne peut les afficher qu'en tant que commentaire. Mais c'est plutôt une limitation de JIRA que de SCM Manager.

Trop tard!
Je devais m'en débarrasser, Désolé

Culte ne m'a pas repondu,
TouLibre n'en veut pas en ce moment.

Marc es-tu intéressé ?

Qu'il ait raison sur le fond ne change rien à la forme. Qu'ils viennent le signifier aux autres est juste un comble.
C'est tout.

Question respect, sans arrogance ! Tu en connais un rayon !

L’hôpital qui se fout de la charité.

Faut dire tout de suite ca part dans du jabber.

Elles n'ont pas l'esprit "Lean Startup", les moules du bouchot.
Pas étonnnant que Non ne veuille pas s'y coller

L'intérêt est pourtant certain: passer d'un communauté virtuelle au réel.

Dommage

Ah oui

Intuitivement on s'attendrait à le trouver sur la page de suivi mais c'est ok

Y'a pas de recherche dans le suivi, non ?

Oui mais de manière pragmatique:

Là dans une entrée de forum:
http://linuxfr.org/forums/general-general/posts/premiers-linux-magazine-a-donner-sur-toulouse

j'aimerais rencontrer qq1 pour lui remettre des bouquins.
Pas un besoin sophistiqué.

Là en fait on n'a pas moyen de contacter quelqu'un sans balancer son contact à la terre entière.
Y'a un ticket dans suivi (Y'a pas de recherche non plus)
2 features intéressantes pourtant

Ca pouvait être pratique pourtant.

Ca n'existe plus les messages privé sur DLFP ?
Je peux faire un détour par Basso si c'est trop compliqué pour les assoces.

Anéfé !

Et pour tout ce qui tourne autour du model driven avec Eclipse,
vas plutôt voir par ici:
http://www.eclipse.org/modeling/

Tout se base sur l'Ecore
http://download.eclipse.org/modeling/emf/emf/javadoc/2.9.0/org/eclipse/emf/ecore/package-summary.html#details
qui est lui-même une implémentation d'une sous-partie du MOF (http://www.omg.org/mof/)

Non je vais voir avec eux ou avec Toulibre.
Merci pour l'info

Et pour l'ambition démesurée:

Ne confonds pas MDA (http://en.wikipedia.org/wiki/Model-driven_architecture) qui fonde l'architecture sur les modèles avec une approche purement top-down et le MDSD (http://en.wikipedia.org/wiki/Model_Driven_Software_Development) qui en fait un usage plus pragmatique.
Les techniques Model-Driven peuvent s'avérer très efficaces utilisées à bon escient y compris pour écrire son propre DSL textuel (Son langage personnalisé).

Jette un coup d'oeil à Xtext:
tutoriel
http://alain-bernard.developpez.com/tutoriels/eclipse/creation-grammaire-xtext/
Site officiel:
https://www.eclipse.org/Xtext/

Relis mon paragraphe plus haut.
Un bon métamodèle et un langage de transfo sont bien plus efficaces.
J'avais testé le XSLT et c'était contreproductif pour notre besoin et pas adapté.
Si tu as cette problématique tourne toi vers des gens compétents.
Il y sûrement des personnes d'Obeo qui traînent par ici prêtes à t'apporter du conseil ou des solutions.
(Sinon envoie un MP)

AMQP à l'air d'être initiative intéressante elle n'a pas l'air d'avoir fédéré beaucoup de monde.

ZeroC introduit plus de couplage et retombe dans les travers de CORBA, il me semble. Ce protocole est trés ancine et n'a jamais vraiment percé. Elles se basent sur les données.

Les autres n'adressent que Java et ne sont donc pas agnostiques

XMPP j'ai du mal à voir comment ca pourrait s'appliquer mais pourquoi pas.

Enfin un autr initailtive que j'aime bien est OSLC ( http://open-services.net/ )
Ca adresse un bus de service ALM (Application Lifcycle Management) est c'est poussé par IBM avec leur plateforme Jazz/RTC.

Mais le core s'appuid sur des ressources en guise de données avec RDF et ca se construit au dessus d'une archi REST.
REST seule est très limité pour le transactionnel.

Pour l'UDDI tu as sans doute raison, en revanche le WSDL est très utilisés.
Et le REST ne résoud pas tout dans des transactions B2B complexes.

La volonté de baser un ESB sur du SOAP pour des web-services interne part d'un bon sentiment. Une réutilisation potentielle en externe à coup de BPEL s'il le faut.

Dans ma boîte, nous avions implémenté un bus de service des années avant la hype SOA et son standard. Il a fallu tout migrer vers un ESB proprio.
C'est un fiasco en terme de réutilisation de service car aucune gouvernance n'a été sérieusement entreprise.
Aujourd'hui, on aimerait se tourner ves un ESB open-source.

Je crois que le mirage du SOA vient surtout du fait que les daicideurs pressés ont imaginé decrire les processus métiers en BPMN, appuyer sur un boutons et virer les DSI.
Mais ca n'a rien à voir avec les caractéristiques du SOAP.

Mais merci d'avoir développé ton point de vue

Justement non.

Ce sont des des langages déclaratifs à la base. Rien à voir avec le XSLT.

La puissance du MDD vient du du meta-metamodel MOF (Meta Object Facility) de l'OMG ( qui permet de décrire tout langage de modélisation standard ou DSLs (Domain Specific Lanaguage).
Son implémentation dans Eclipse est l'Ecore. EMF (Eclipse Modeling Framework) fournit toutes les facilités pour décrire les métamodèles des langages et les manipuler.
Pour une transformation, il faut donc décrire les metamodèles de départ (des cartridges existent pour les standards)et d'arrivée. Ca génère automatiquement tout le code de manipulation des modèles, puis écrire une transformation dans un des langage pré-cités (ATL et pas ATI d'ailleurs pas facile avec une tablette et son auto-correction).
Ces langages sont beaucoup plus compréhensibles et puissants que du XSLT.

Le XML n'est qu'un format de persistence. Tout se fait en mémoire avec une API adéquate. Et tout ca peut être beaucoup plus rapidement mis en place qu'avec du XSLT.

Pour du M2T Model 2 Text, tu utilse un langage de template.
Tu écrit ton texte final statique et à certains endroits tu "injectes" le code pour aller chercher les bonnes infos dans ton modèles source.

Le seuls truc qui reste merdique est la génération documentaire.
Avec le code on peut laisser la place à des balises protected pour que le code puisse être modidfié et par ecrasé lors des générations ultérieures. Avec un document Word ou odf ce n'est pas possible.

La déchetterie de mon village accueillera donc ces cartons bras ouverts

Dsl, je n'escompte pas péter à Lyon dans un avenir proche.
Dommage

Oui enfin, Linux Mag, culturellement, ça n'a pas grand chose à voir avec Marguerite Duras ou Nino Ferrer ( http://www.bibliotheque.toulouse.fr/NinoFerrer.html )
Mais merci du conseil