1. Effectivement, la gamme actuelle de logiciels Nuxeo ne s'adresse pas aux boutiques (DSI ou intégrateurs) exclusivement PHP ou .NET.
2. Distinguons bien Nuxeo EP, qui est le fondement de notre offre, de Nuxeo RCP qui est une "cerise sur le gâteau", un moyen de développer des applications métiers dont le coût de développement est justifié par le gain de productivité des personnes qui vont utiliser l'application, par rapport à une approche client léger (qui a elle même son coût de développement, d'ailleurs, et qui n'est pas forcément moins élevé).
3. On se place donc bien dans la situation où les développeurs auxquels on s'adressent connaissent bien Java. En général, ils connaissent bien Ant, et le plus souvent (c'est en tout cas ce que nous avons constaté dans 100% des cas chez nos clients et partenaires), ils utilisent Eclipse comme IDE. Ils ont l'expérience d'un ou plusieurs serveurs d'applications, et dans la plupart des cas cela inclut JBoss. Maven était moins bien connu il y a deux ans quand on a commencé le projet Nuxeo 5, mais on a constaté depuis que de nombreux projets Java libres étaient passés à Maven et que ça connaissance se répandait dans l'industrie des services. De toute façon, les connaissances Maven nécessaires pour démarrer, builder et déployer un projet Nuxeo tiennent en deux pages de texte (il y a trois ou quatre options différents de la commande "mvn" à connaître), et par ailleurs des plugins Maven sont en train de mûrir pour Eclipse (et Netbeans).
4. Pour en revenir à la philosophie générale, et à la prospective, nous avons effectivement choisi de nous appuyer sur les approches les plus standards du monde Java, mais en même temps en tirant partie du dynamisme insufflé depuis la sortie de Java 5 et Java EE 5, de façon à faciliter la vie des développeurs qui travaillent sur notre plateforme.
Parmi les points sur lesquels nous comptons travailler dans les mois qui viennent (entre autres) et sur lesquels bien sûr nous accueillons à bras ouverts toute contribution (-> http://www.nuxeo.org/sections/community/ ), qu'elle soit sous forme de code, de plugins ou simplement d'idées:
- La réalisation d'un IDE (en fait, un profil pour Eclipse, avec une selection des plugins qui vont bien + quelques plugins spécifiques) dédié au développement d'applications sur la plateforme Nuxeo.
- Le déploiement de Nuxeo EP dans d'autres serveurs d'applications que JBoss.
- Une version de Nuxeo dédiée au développement d'application web légères, qui pourra être customisée par des développeurs qui ne connaissent pas Java.
S.
"There's no such thing as can't. You always have a choice." - Ken Gor
Le texte est à présent également signé par atReal ( http://www.atreal.net ) "éditeur de logiciels GED et espaces collaboratifs et de logiciels libres métiers pour les collectivités locales. atReal a été créé en janvier 2003 et bénéficie du soutien d'Oséo/Anvar pour son effort de R&D, auquel elle consacre plus de 20% de son CA.".
Les signataires de la lettre font tous de la R&D de manière très substancielle, ce qui contredit de manière factuelle et indéniables les allégations de l'AFDEL.
"There's no such thing as can't. You always have a choice." - Ken Gor
A noter que notre initiative est également soutenue officiellement par plusieurs poids lourds du logiciel libres: Red Hat, Ingres, l'AFUL et le consortium OW2 (anciennement ObjectWeb).
"There's no such thing as can't. You always have a choice." - Ken Gor
Nuxeo EP n'est pas un portail, donc il n'y a pas vraiment lieu de comparer Nuxeo et Liferay, JBoss Portal, Jahia, etc.
Notre idée générale est de ne jamais réinventer la roue, mais de nous appuyer sur des logiciels existants, autant que possible.
Comme il existe une offre déjà assez riche de portails Java (basés sur la JSR-168, autrement dit l'API de portlet), nous avons choisi de nous appuyer, lorsque c'est utile, sur ces portails.
Nous sommes ouverts à des collaborations avec les gens qui font des portails, ou dont le métier est de faire de l'intégration autour de ces portails, pour enrichir cette intégration.
S.
"There's no such thing as can't. You always have a choice." - Ken Gor
Parmi les projets utilisés par la plateforme, j'ai oublié de mentionner Restlet (http://www.restlet.org/) qui est utilisé (et c'est une des nouveautés des la 5.1) pour implémenter les web services RESTful dans Nuxeo.
S.
"There's no such thing as can't. You always have a choice." - Ken Gor
Pour des besoins de collaboration simples (type ce qu'on peut faire avec un Wiki par exemple), il est bon de minimiser les contraintes, tout en fournissant des outils comme ceux que tu cites (alertes mail, RSS, alertes de messagerie instantannée...). C'est ce que nous fournissons par défaut dans notre offre collaborative "clef en main".
En revanche, pour des besoins de gestion documentaire d'entreprise (ECM), le workflow, la gestion du cycle de vie des documents, la gestion de métadonnées complexes, la gestion des relations de dépendances entre documents, l'application de règles de conservation, etc. sont indispensables, car ils servent à s'assurer de l'efficacité des processus métiers et de la conformité des processus documentaires avec les standards de qualité interne à l'entreprise, ainsi qu'aux règlementations (par exemple, comptables, comme la LSE ou la loi Sarbanes-Oxley, ou métier, comme dans c'est le cas dans des professions comme les commissaires aux comptes ou l'industrie nucléaire) en vigueur.
"There's no such thing as can't. You always have a choice." - Ken Gor
Par rapport à notre projet, Nuxeo EP (http://www.nuxeo.org/ ), je note avec plaisir l'utilisation d'un certain nombre de technologies similaires, notamment un dépôt de documents JCR (comme Jackrabbit). Je vois aussi que nous avons la même (bonne) idée de développer des plugins pour les suites bureautiques du marché afin de faciliter l'utilisation de la GED depuis les outils dont les utilisateurs ont l'habitude.
La principale différence que je vois (à première vue), est que l'architecture de Nuxeo a été pensée pour être complètement extensible, grâce à un système de points d'extensions et de plugins, inspiré par l'architecture d'Eclipse et par le standard OSGi (http://www.osgi.org ). Cela permet aux intégrateurs d'utiliser facilement Nuxeo en tant que framework et plateforme, et de développer facilement ou d'intégrer les fonctions complémentaires qui sont nécessaires lorsqu'ils ont à réaliser des projets complexes de GED.
Une autre différence importante est la présence dans Nuxeo d'un moteur de workflow, indispensable à notre sens en gestion documentaire collaborative.
Enfin, j'en profite pour faire passer un message: Nuxeo SAS recrute (en particulier des développeurs, débutants voire stagiaires, ou expérimentés), pour travailler sur et autour de son projet libre Nuxeo. Les compétences que nous cherchons sont principalement les technos Java EE open source, et une première expérience de la GED ou du travail collaboratif.
JEE = Java EE = Java Enterprise Edition. C'est le nouveau nom de J2EE depuis qu'on est passé à la version 5. En gros c'est tous les frameworks qui permettent de faire des applications "d'entreprise" au-dessus de Java, et notamment: des application web (servlets), des applications distribuées (RMI, EJB, etc...). Comme tu le vois, on rajoute encore des acronymes derrière. Tout cela est à présent défini dans le cadre du JCP (Java Community Process, encore un acronyme), auquel chaque développeur concerné peut participer librement.
RCP = "Rich Client Platform" = environnement de client riche basé sur Eclipse (depuis la version 3.0 d'Eclipse).
Nuxeo EP = "Nuxeo Enterprise Platform". C'est le nom que nous avons donné à la partie serveur de notre projet.
ECM = "Enterprise Content Management" ou "gestion de contenu d'entreprise". Discipline et technologies qui visent à gérer l'intégralité du cycle de vie des documents dans une entreprise ou une administration.
JCR = "Java Content Repository", une API qui a été définie dans le cadre du JCP (cf supra) pour accéder de manière standard à des dépôts de contenu de manière indépendante de la solution utilisée (du moment que c'est du Java, quand même).
(J'en profite pour remercier le ou les modérateurs qui ont rajouté les liens pertinents vers Wikipedia à mon post initial.)
Pour ce qui est des petites structures, ce que nous proposons d'adresse en priorité à des boîtes de 100 personnes ou plus, dans la mesure où il s'agit avant tout d'un framework paramêtrable et extensible en fonction des besoins métiers. Mais la version générique packagée devrait convenir aussi aux besoins des petites sturctures (5-100 personnes.)
"Nuxeo Core peut être utilisé à la fois en environnement Java EE et en environnement client riche"
-> Il faut conprendre "Nuxeo peut être embarqué à la fois dans un client (par exemple une application RCP) et un serveur (par exemple un conteneur EJB3, mais aussi, au moins a terme, un Tomcat, etc.)".
je suis heureux d'apprendre que Jython est beaucoup utilisé dans le domaine du calcul scientifique et de la visualisation. Je savais que c'était déja le cas pour CPython, grâce à différents systèmes d'interfaces avec C (SWIG, Pyrex), C++ (SWIG, BOOST, SIP, etc.) et Fortran - cf. http://wiki.python.org/moin/IntegratingPythonWithOtherLangua(...) - qui sont particulièrement utiles dans le domaine du calcul scientifiques.
Comme je l'ai écrit, Jython était une idée géniale au départ (même si d'autres langages de scripts, et notamment Tcl, avaient eu une implémentation sur la JVM avant Python, Jython offrait l'avantage de présenter un modèle objet similaire à celui de Java).
J'ai moi-même utilisé Jython il y a quelques mois pour scripter rapidement quelques tests sur Jackrabbit, au tout début de notre projet de migration.
Microsoft a récemment (il y a deux ans quand même) investi sur Python en embauchant le développeur d'IronPython, portage de Python sur la CLR .NET.
Face à cela, Sun semble avoir fait le choix de Ruby, en embauchant le mois dernier les deux développeurs de JRuby (portage de Ruby sur la JVM, tout le monde l'aura deviné).
La JSR 223 promet une bonne intégration entre l'environement Java et les langages de scripts qui ont été portés sur la JVM. Il y a déja une vingtaine de langages qui répondent à la spec, dont: Python, TCL, Ruby, JavaScript, PHP, Groovy, Scheme, Pnuts, Judoscript, etc.
On constate qu'aucun expert Python (aucun connu de moi, en tout cas), ne semble avoir participé au groupe d'expert dans le cadre du JCP: http://www.jcp.org/en/jsr/detail?id=223 Mais ce n'est sans doute pas un problème, ca montre juste un désintérêt, il me semble.
Maintenant, si personne ne se motive pour mettre Jython à jour avec la version 2.5 de Python (qui présente quand même de très gros changements avec la version 2.1, en fait c'est dans les 2.2, 2.3 et 2.4 qu'ont été introduits les "new style classes", les métaclasses, les annotations, etc. - bref toutes les features modernes de Python), il est clair que les gens vont se tourner vers d'autres langages de scripts pour scripter leurs applis Java.
J'en suis le premier désolé. C'est la règle du logiciel libre (et du logiciel en général): s'il n'y a personne pour développer, ca n'avance plus.
D'un autre côté, c'est un projet passionnant, je trouve, et il y a peut-être des lecteurs de LinuxFR à la recherche d'un projet dans le domaine de la compilation et de l'implémentation d'un langage moderne qui seront tentés. Peut-être même qu'il y a de l'inspiration à chercher du côté d'IronPython.
Bah oui, les temps changent vite dans le monde de l'informatique, et comme on dit aussi, il n'y a que les imbéciles qui ne changent pas d'avis (en particulier quand la réalité a changé entre temps).
Ce qu'on a toujours dit, et qui ne change pas, depuis l'article fondateur de John Ousterhout en 1998 (http://en.wikipedia.org/wiki/John_Ousterhout ), Scripting: Higher Level Programming for the 21st Century (http://home.pacbell.net/ouster/scripting.html ), c'est qu'il y a une place pour les deux types de langages, les langages de scripts et les langages de programmation de composants (qu'il appelle lui "langages de programmation système"), et que les deux sont complémentaires:
Scripting languages, on the other hand, have actually generated significant software reuse. They use a model where interesting components are built in a system programming language and then glued together into applications using the scripting language. This division of labor provides a natural framework for reusability. Components are designed to be reusable, and there are well-defined interfaces between components and scripts that make it easy to use components.
(Là c'est Ousterhout qui parle).
Donc la question n'est pas: tel langage est meilleur que tel autre, mais tel langage (+ l'ecosystème qui va avec, les librairies et les outils de développement, notamment) est plus adapté que tel autre à tel type de problème. Notre métier, c'est l'ECM, et pour faire des composants d'ECM, le meilleur choix aujourd'hui, à notre humble avis, c'est Java, indépendamment des qualités que Python (ou Ruby, ou Groovy, ou JavaScript/ECMAScript) garde par ailleurs. Ces composants d'ECM sont ensuite assemblés, configurés, scriptés, en utilisant des outils plus souples, notamment des descripteurs de types de documents (ex: schémas XML), de formulaires (ex: XForms), des fichiers de configuration de composants (XML), des règles métier, des workflows (ex: BPEL), des scripts.
1. Tu ne cites qu'un bout de la FAQ, celui qui t'arrange. Les raisons du changement sont doubles, techniques et commerciales, et, contraîrement à ce que tu as l'air de penser, les deux ne s'opposent pas. L'excellence technique n'a de sens que si elle peut être utilisée en vrai, dans le contexte d'un système d'information, avec des équipes à formers, etc.
2. Ta citation n'est pas extraite de la dépêche de LinuxFR, mais de notre site. La dépêche en elle-même se focalise sur les aspects techniques de notre annonce, les produits libre et les technologies ouvertes que l'on utilise, le fait que le code est disponible et qu'on a commencé à releaser un module intéressant (en attendant la suite...).
Donc non seulement je ne suis pas d'accord avec toi, mais l'intérêt suscité par cette dépêche dans la communauté LinuxFR (108 commentaires en 1 jour 1/2, ca me parait pas mal du tout :) ) m'incitent à renouveler l'initiative lorsque nous annoncerons de nouveaux modules, en suivant la roadmap (http://www.nuxeo.org/sections/about/roadmap ), à commencer par Nuxeo Core et Nuxeo EP.
Merci à tous pour vos commentaires, et à certains pour votre soutien.
A propos de la formation des gens à Python/Zope: former les développeurs à Python, normalement c'est pas trop dur. Une journée pour avoir de bonnes bases, et ensuite on apprend sur le tas. Bien sûr, entre la réalité et la perception, il y a un écart: il faut que les gens soient motivés pour apprendre, il faut que les responsables ne se braquent pas contre cette idée, etc. Donc effectivement, au niveau perception, on a un obstacle à franchir.
Le deuxième obstacle c'est Zope: Zope 2 est en voie d'obsolescence, le futur c'est Zope 3. Ou pas. En l'état, l'état de l'art consiste à mélanger du Zope 2 et du Zope 3 en utilisant un "bridge" baptisé Five. Donc en terme de formation, un développeur pour bien maitriser la plateforme doit connaitre Zope 2, Zope 3 (qui n'a plus grand chose à voir avec Zope 2, c'est vraiment des concepts complètement différents) et Five (qui a ses propres spécificités). Et la ca devien t vraiment difficile de motiver les gens pour apprendre ces trois technos, sachant qu'il y en a deux qui seront bientôt obsolètes (ou pas).
Zope était le choix rationnel quand on voulait faire du Web en Python en 2000, maintenant il y a Django et Turbogears. La communauté Python est partagée sur ce sujet. C'est assez compliqué à expliquer quand on ne suit pas tout ca de près, mais bon l'impression générale c'est qu'on voit pas trop où ca va.
A propos de Jython: Jython ( http://www.jython.org/ ) c'était une idée géniale en 2000, quelque chose de super prometteur, qui a été embarqué dans les 2-3 années qui ont suivi dans pas mal d'applications (libres et propriétaires, et oui!). Le problème, c'est que la version de 2006 n'a pas évolué (ou si peu) par rapport à la version de 2000. On est toujours bloqué à la version 2.1 de Python, alors que "CPython", l'implémentation "standard" vient de sortir en 2.5. Il y a donc des grosses différences entre les deux. Donc à l'heure actuelle plus grand monde ne s'intéresse à Jython, et il n'y a plus personne pour bosser dessus.
En l'état, on n'a pas encore choisi quel sera le langage de script de la plateforme Nuxeo 5. Mais rassure-toi, il y en aura un ! Pour l'instant on hésite encore entre JavaScript (et oui!), JRuby, Jython et Groovy. Le prérequis évident, c'est que le langage qu'on choisira devra tourner sur la JVM et s'interfacer avec Java conformément à la JSR 223 (http://jcp.org/en/jsr/detail?id=223).
"Tu imagines": c'est ca le pb, tu imagines des trucs mais bon c'est pas comme ca en vrai.
"Java est tout sauf libre": je ne parle pas dans ma phrase de Java (relis ce que j'ai écris), mais des outils et des librairies libres. Je parle d'Eclipse, de Jackrabbit, de Lucene, de JBoss, de jPBM, etc. Alors ne me fais pas dire ce que je n'ai pas dit STP.
"Java est plus vendeur que Python": ben oui, c'est ca l'objet (outre les aspects technologiques) du changement. Ca correspond mieux aux schémas directeurs dans pas mal de boites ou de ministères. C'est plus facile à faire accepter dans les SSII. C'est plus facile à intégrer dans les SI. Y a plus de librairies libres disponibles. Etc. Faire le meilleur logiciel du monde, si personne ne l'utilise, ca ne sert à rien. Donc c'est important d'utiliser des technologies que les gens acceptent facilement.
"Après on mets ses convictions de côté": Avoir des convictions, c'est bien, mais il faut aussi qu'elles soient conformes à la réalité. Et la réalité change, alors les convictions doivent aussi s'adapter. Le choix de Zope était pertinent pour nous en 2000, il ne l'est plus en 2006.
"Je ne suis pas décideur": je suis sûr que tu prends des décisions, la preuve. Je suis désolé que notre nouvelle orientation ne te convienne pas, notre objectif est bien qu'il y a des développeurs qui soient convaincus de la pertinence de notre choix. Mais si ce n'est pas toi, il y en aura d'autres.
Donc sans rancune, et on se donne RDV quand on aura les première versions "montrables" (i.e. d'ici un mois).
"Inventaire à la Prévert": comme je l'ai écrit dans d'autres commentaires, on est dans le cadre d'une architecture à base de composants. Il est important de bien identifier chacun des composants importants qui sont utilisés dans l'architecture, et aussi, et peut-être surtout, sur quelles spécifications standards ils s'appuient, lorsque c'est le cas (ex: JCR, aka JSR-170, JSF, aka JSR-252, etc.).
"je pense que le consortium ObjectWeb pèse de tout son poids idéologique": je pense surtout que c'est "le marché" qui pèse en faveur de Java EE. Le consortium ObjecWeb participe à son niveau à l'écosystème Java libre, comme la Fondation Apache, la fondation Eclipse, JBoss, et bien d'autres, petits ou grands. Il s'agit d'un mouvement de fond, modelé par de nombreux acteurs, aussi bien côté vendeurs que côté utilisateurs, et dans lequel l'excellence technique est un facteur important, mais aussi la capacité à susciter l'adhésions des autres acteurs autour d'une technologie donnée.
Merci de pointer vers notre annonce de recrutement, ca nous aidera peut-être à trouver les bonnes personnes.
Mais d'un autre côté, tu prends les choses un peu à l'envers:
1. Nuxeo cherche à recruter, parce que Nuxeo est une boite en croissance et que pour faire tous les projets qu'on a à faire (sans parler de tous ceux qu'on va arriver à vrendre plus facilement parce qu'on est passé à Java), on a besoin de développeurs.
2. Vu qu'on a changé de techno, autant que le profil du poste corresponde à ce que les gens vont faire une fois embauché: du Java, avec des outils et des librairies libres.
Maintenant, bien sûr qu'on a déja des compétences, vu la base de code qu'on a déjà écrite: http://svn.nuxeo.org/
Enfin, en ce qui concerne l'aspect commercial, ne t'inquiète pas: ce switch a été décidé en partie pour répondre aux attentes des clients et des partenaires.
Maintenant on le fait en plein succès, avec des projets énormes en cours et des clients et partenaires qui nous suivent à 100%. Ou si on préfère, c'est en parlant à ces clients et partenaires qu'on est arrivé à cette idée de changement - après avoir été convaincus que techniquement on aurait uns solution non seulement qui tient la route, mais qui nous permet d'allier la souplesse de Zope avec la robustesse de Java EE tout en tirant parti de tous les composants libres de l'écosystème Java.
Pour les clients actuels, on a prévu de continuer à supporter leurs applications pendant 3 ans, et de les accompagner si ils le souhaitent vers la nouvelle plateforme. Cf. la FAQ: http://www.nuxeo.com/java-switch/about-cps
Pour ce qui est de l'équipe, on est développeur avant tout, et probablement plus expert d'un domaine d'application (l'ECM) que d'un langage (Python vs. Java).
Mon témoignage personnel: j'ai découvert Java comme tout le monde en 1996, et Python quelques mois après. J'ai fait de Python mon langage de choix, et je me suis un peu investi dans sa promotion en France. Maintenant j'aime toujours Python (le langage) mais je constate que dans l'univers Java, il y a une pléthore (i.e. plus qu'en Python) de librairies libres utilisables et d'outils de développement qui rendent la vie du développeur plus facile. Ca évite d'avoir à "réinventer la roue" dans bien des domaines, ou utiliser des librairies à moitié finies.
Bref, il y a une place pour Python (ou Ruby, ou Groovy, ou d'autres langages de scripts) mais aussi pour un langage comme Java. L'idéal étant d'arriver à faire jouer les deux ensemble, ce qui est malheureusement suboptimal dans le cas de Python, dans la mesure où l'implémentation de Python pour la JVM, Jython (http://www.jython.org/), très novatrice à son époque (circa 2000), ne bouge plus depuis des années, et en est toujours à la version 2.1 des spécifications du langage alors que celui-ci vient tout juste de passer à la version 2.5.
[^] # Re: Coût d'une telle solution
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo RCP 2.0 : plateforme client riche pour applications documentaires et multimédias. Évalué à 2.
Quelques éléments de réponse:
1. Effectivement, la gamme actuelle de logiciels Nuxeo ne s'adresse pas aux boutiques (DSI ou intégrateurs) exclusivement PHP ou .NET.
2. Distinguons bien Nuxeo EP, qui est le fondement de notre offre, de Nuxeo RCP qui est une "cerise sur le gâteau", un moyen de développer des applications métiers dont le coût de développement est justifié par le gain de productivité des personnes qui vont utiliser l'application, par rapport à une approche client léger (qui a elle même son coût de développement, d'ailleurs, et qui n'est pas forcément moins élevé).
3. On se place donc bien dans la situation où les développeurs auxquels on s'adressent connaissent bien Java. En général, ils connaissent bien Ant, et le plus souvent (c'est en tout cas ce que nous avons constaté dans 100% des cas chez nos clients et partenaires), ils utilisent Eclipse comme IDE. Ils ont l'expérience d'un ou plusieurs serveurs d'applications, et dans la plupart des cas cela inclut JBoss. Maven était moins bien connu il y a deux ans quand on a commencé le projet Nuxeo 5, mais on a constaté depuis que de nombreux projets Java libres étaient passés à Maven et que ça connaissance se répandait dans l'industrie des services. De toute façon, les connaissances Maven nécessaires pour démarrer, builder et déployer un projet Nuxeo tiennent en deux pages de texte (il y a trois ou quatre options différents de la commande "mvn" à connaître), et par ailleurs des plugins Maven sont en train de mûrir pour Eclipse (et Netbeans).
4. Pour en revenir à la philosophie générale, et à la prospective, nous avons effectivement choisi de nous appuyer sur les approches les plus standards du monde Java, mais en même temps en tirant partie du dynamisme insufflé depuis la sortie de Java 5 et Java EE 5, de façon à faciliter la vie des développeurs qui travaillent sur notre plateforme.
Parmi les points sur lesquels nous comptons travailler dans les mois qui viennent (entre autres) et sur lesquels bien sûr nous accueillons à bras ouverts toute contribution (-> http://www.nuxeo.org/sections/community/ ), qu'elle soit sous forme de code, de plugins ou simplement d'idées:
- La réalisation d'un IDE (en fait, un profil pour Eclipse, avec une selection des plugins qui vont bien + quelques plugins spécifiques) dédié au développement d'applications sur la plateforme Nuxeo.
- Le déploiement de Nuxeo EP dans d'autres serveurs d'applications que JBoss.
- Une version de Nuxeo dédiée au développement d'application web légères, qui pourra être customisée par des développeurs qui ne connaissent pas Java.
S.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Autres soutiens de la lettre
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Rapport Attali : les éditeurs de logiciels libres/opensource dénoncent les allégations infondées de l'AFDEL et sa méconnaissance de l'industrie. Évalué à 1.
Je n'ai aucune compétence, un intérêt modéré, et absolument pas le temps, pour étudier le reste du rapport.
S.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Peu clair
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Rapport Attali : les éditeurs de logiciels libres/opensource dénoncent les allégations infondées de l'AFDEL et sa méconnaissance de l'industrie. Évalué à 1.
Et soutenu par l'APRIL ( http://www.april.org/ ) et l'association Libertis ( http://www.libertis.org/ ).
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Peu clair
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Rapport Attali : les éditeurs de logiciels libres/opensource dénoncent les allégations infondées de l'AFDEL et sa méconnaissance de l'industrie. Évalué à 3.
http://www.aful.org/presse/rapport-attali-editeurs-logiciels(...)
et avec quelques signatures supplémentaires depuis la publication par LinuxFR.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Peu clair
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Rapport Attali : les éditeurs de logiciels libres/opensource dénoncent les allégations infondées de l'AFDEL et sa méconnaissance de l'industrie. Évalué à 2.
-> sous tes yeux ;)
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Autres soutiens de la lettre
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Rapport Attali : les éditeurs de logiciels libres/opensource dénoncent les allégations infondées de l'AFDEL et sa méconnaissance de l'industrie. Évalué à 2.
"There's no such thing as can't. You always have a choice." - Ken Gor
# Autres soutiens de la lettre
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Rapport Attali : les éditeurs de logiciels libres/opensource dénoncent les allégations infondées de l'AFDEL et sa méconnaissance de l'industrie. Évalué à 7.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Java vraiment GPL?
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo annonce la version 5.1 de sa plateforme d'ECM libre. Évalué à 2.
S.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Comparaison Nuxeo 5.1 avec un portail
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo annonce la version 5.1 de sa plateforme d'ECM libre. Évalué à 4.
Nuxeo EP n'est pas un portail, donc il n'y a pas vraiment lieu de comparer Nuxeo et Liferay, JBoss Portal, Jahia, etc.
Notre idée générale est de ne jamais réinventer la roue, mais de nous appuyer sur des logiciels existants, autant que possible.
Comme il existe une offre déjà assez riche de portails Java (basés sur la JSR-168, autrement dit l'API de portlet), nous avons choisi de nous appuyer, lorsque c'est utile, sur ces portails.
L'intégration JSR 168 est actuellement disponible dans des plugins d'extension dans la "forge" Nuxeo (nuxeo-portlet-* dans [http://svn.nuxeo.org/trac/nuxeo/browser/sandbox]).
Nous sommes ouverts à des collaborations avec les gens qui font des portails, ou dont le métier est de faire de l'intégration autour de ces portails, pour enrichir cette intégration.
S.
"There's no such thing as can't. You always have a choice." - Ken Gor
# Oubli: Restlet
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo annonce la version 5.1 de sa plateforme d'ECM libre. Évalué à 3.
S.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Nuxeo
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Sortie de la première version du projet PengYou. Évalué à 1.
Nous avons un plugin Firefox ici:
http://svn.nuxeo.org/trac/nuxeo/browser/NXFirefoxHelper/trun(...)
et un plugin IE là:
http://svn.nuxeo.org/trac/nuxeo/browser/NXIEHelper/trunk
Les plugins OOo et MSO viendront ensuite.
2. Le workflow
Pour des besoins de collaboration simples (type ce qu'on peut faire avec un Wiki par exemple), il est bon de minimiser les contraintes, tout en fournissant des outils comme ceux que tu cites (alertes mail, RSS, alertes de messagerie instantannée...). C'est ce que nous fournissons par défaut dans notre offre collaborative "clef en main".
En revanche, pour des besoins de gestion documentaire d'entreprise (ECM), le workflow, la gestion du cycle de vie des documents, la gestion de métadonnées complexes, la gestion des relations de dépendances entre documents, l'application de règles de conservation, etc. sont indispensables, car ils servent à s'assurer de l'efficacité des processus métiers et de la conformité des processus documentaires avec les standards de qualité interne à l'entreprise, ainsi qu'aux règlementations (par exemple, comptables, comme la LSE ou la loi Sarbanes-Oxley, ou métier, comme dans c'est le cas dans des professions comme les commissaires aux comptes ou l'industrie nucléaire) en vigueur.
"There's no such thing as can't. You always have a choice." - Ken Gor
# Nuxeo
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Sortie de la première version du projet PengYou. Évalué à 4.
Par rapport à notre projet, Nuxeo EP (http://www.nuxeo.org/ ), je note avec plaisir l'utilisation d'un certain nombre de technologies similaires, notamment un dépôt de documents JCR (comme Jackrabbit). Je vois aussi que nous avons la même (bonne) idée de développer des plugins pour les suites bureautiques du marché afin de faciliter l'utilisation de la GED depuis les outils dont les utilisateurs ont l'habitude.
La principale différence que je vois (à première vue), est que l'architecture de Nuxeo a été pensée pour être complètement extensible, grâce à un système de points d'extensions et de plugins, inspiré par l'architecture d'Eclipse et par le standard OSGi (http://www.osgi.org ). Cela permet aux intégrateurs d'utiliser facilement Nuxeo en tant que framework et plateforme, et de développer facilement ou d'intégrer les fonctions complémentaires qui sont nécessaires lorsqu'ils ont à réaliser des projets complexes de GED.
Une autre différence importante est la présence dans Nuxeo d'un moteur de workflow, indispensable à notre sens en gestion documentaire collaborative.
Enfin, j'en profite pour faire passer un message: Nuxeo SAS recrute (en particulier des développeurs, débutants voire stagiaires, ou expérimentés), pour travailler sur et autour de son projet libre Nuxeo. Les compétences que nous cherchons sont principalement les technos Java EE open source, et une première expérience de la GED ou du travail collaboratif.
Le détail de l'annonce est ici: http://www.nuxeo.com/nuxeo/jobs/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: i (comme point info)
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo Core 1.0 disponible pour la gestion de contenu d'entreprise. Évalué à 3.
RCP = "Rich Client Platform" = environnement de client riche basé sur Eclipse (depuis la version 3.0 d'Eclipse).
Nuxeo EP = "Nuxeo Enterprise Platform". C'est le nom que nous avons donné à la partie serveur de notre projet.
ECM = "Enterprise Content Management" ou "gestion de contenu d'entreprise". Discipline et technologies qui visent à gérer l'intégralité du cycle de vie des documents dans une entreprise ou une administration.
JCR = "Java Content Repository", une API qui a été définie dans le cadre du JCP (cf supra) pour accéder de manière standard à des dépôts de contenu de manière indépendante de la solution utilisée (du moment que c'est du Java, quand même).
(J'en profite pour remercier le ou les modérateurs qui ont rajouté les liens pertinents vers Wikipedia à mon post initial.)
Pour ce qui est des petites structures, ce que nous proposons d'adresse en priorité à des boîtes de 100 personnes ou plus, dans la mesure où il s'agit avant tout d'un framework paramêtrable et extensible en fonction des besoins métiers. Mais la version générique packagée devrait convenir aussi aux besoins des petites sturctures (5-100 personnes.)
S. Fermigier -- PDG, Nuxeo (http://www.nuxeo.com/)
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: client riche
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo Core 1.0 disponible pour la gestion de contenu d'entreprise. Évalué à 5.
-> Il faut conprendre "Nuxeo peut être embarqué à la fois dans un client (par exemple une application RCP) et un serveur (par exemple un conteneur EJB3, mais aussi, au moins a terme, un Tomcat, etc.)".
Quant à la différence entre client riche et RIA, elle me paraît claire: une application RIA s'exécute dans un navigateur (cf. AJAX, Web 2.0, etc.), une application RCP s'exécute en standalone (type Eclipse RCP, Netbeans RCP, le truc de Microsoft). Cf. ces très intéressants slides de Didier Girard (http://www.tni-software.com/commun/docs/bureaumetier_eclipse(...) - et les miens pendant qu'on y est (http://www.tni-software.com/commun/docs/nuxeorcp_apogee_prez(...)
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Former des développeurs Python/Zope compétents
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 2.
S.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Former des développeurs Python/Zope compétents
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 3.
je suis heureux d'apprendre que Jython est beaucoup utilisé dans le domaine du calcul scientifique et de la visualisation. Je savais que c'était déja le cas pour CPython, grâce à différents systèmes d'interfaces avec C (SWIG, Pyrex), C++ (SWIG, BOOST, SIP, etc.) et Fortran - cf. http://wiki.python.org/moin/IntegratingPythonWithOtherLangua(...) - qui sont particulièrement utiles dans le domaine du calcul scientifiques.
Comme je l'ai écrit, Jython était une idée géniale au départ (même si d'autres langages de scripts, et notamment Tcl, avaient eu une implémentation sur la JVM avant Python, Jython offrait l'avantage de présenter un modèle objet similaire à celui de Java).
J'ai moi-même utilisé Jython il y a quelques mois pour scripter rapidement quelques tests sur Jackrabbit, au tout début de notre projet de migration.
Microsoft a récemment (il y a deux ans quand même) investi sur Python en embauchant le développeur d'IronPython, portage de Python sur la CLR .NET.
Face à cela, Sun semble avoir fait le choix de Ruby, en embauchant le mois dernier les deux développeurs de JRuby (portage de Ruby sur la JVM, tout le monde l'aura deviné).
La JSR 223 promet une bonne intégration entre l'environement Java et les langages de scripts qui ont été portés sur la JVM. Il y a déja une vingtaine de langages qui répondent à la spec, dont: Python, TCL, Ruby, JavaScript, PHP, Groovy, Scheme, Pnuts, Judoscript, etc.
On constate qu'aucun expert Python (aucun connu de moi, en tout cas), ne semble avoir participé au groupe d'expert dans le cadre du JCP: http://www.jcp.org/en/jsr/detail?id=223 Mais ce n'est sans doute pas un problème, ca montre juste un désintérêt, il me semble.
Maintenant, si personne ne se motive pour mettre Jython à jour avec la version 2.5 de Python (qui présente quand même de très gros changements avec la version 2.1, en fait c'est dans les 2.2, 2.3 et 2.4 qu'ont été introduits les "new style classes", les métaclasses, les annotations, etc. - bref toutes les features modernes de Python), il est clair que les gens vont se tourner vers d'autres langages de scripts pour scripter leurs applis Java.
J'en suis le premier désolé. C'est la règle du logiciel libre (et du logiciel en général): s'il n'y a personne pour développer, ca n'avance plus.
D'un autre côté, c'est un projet passionnant, je trouve, et il y a peut-être des lecteurs de LinuxFR à la recherche d'un projet dans le domaine de la compilation et de l'implémentation d'un langage moderne qui seront tentés. Peut-être même qu'il y a de l'inspiration à chercher du côté d'IronPython.
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: La pub débarque sur linuxfr!
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 5.
Ce qu'on a toujours dit, et qui ne change pas, depuis l'article fondateur de John Ousterhout en 1998 (http://en.wikipedia.org/wiki/John_Ousterhout ), Scripting: Higher Level Programming for the 21st Century (http://home.pacbell.net/ouster/scripting.html ), c'est qu'il y a une place pour les deux types de langages, les langages de scripts et les langages de programmation de composants (qu'il appelle lui "langages de programmation système"), et que les deux sont complémentaires:
(Là c'est Ousterhout qui parle).
Donc la question n'est pas: tel langage est meilleur que tel autre, mais tel langage (+ l'ecosystème qui va avec, les librairies et les outils de développement, notamment) est plus adapté que tel autre à tel type de problème. Notre métier, c'est l'ECM, et pour faire des composants d'ECM, le meilleur choix aujourd'hui, à notre humble avis, c'est Java, indépendamment des qualités que Python (ou Ruby, ou Groovy, ou JavaScript/ECMAScript) garde par ailleurs. Ces composants d'ECM sont ensuite assemblés, configurés, scriptés, en utilisant des outils plus souples, notamment des descripteurs de types de documents (ex: schémas XML), de formulaires (ex: XForms), des fichiers de configuration de composants (XML), des règles métier, des workflows (ex: BPEL), des scripts.
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: La pub débarque sur linuxfr!
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 3.
1. Tu ne cites qu'un bout de la FAQ, celui qui t'arrange. Les raisons du changement sont doubles, techniques et commerciales, et, contraîrement à ce que tu as l'air de penser, les deux ne s'opposent pas. L'excellence technique n'a de sens que si elle peut être utilisée en vrai, dans le contexte d'un système d'information, avec des équipes à formers, etc.
2. Ta citation n'est pas extraite de la dépêche de LinuxFR, mais de notre site. La dépêche en elle-même se focalise sur les aspects techniques de notre annonce, les produits libre et les technologies ouvertes que l'on utilise, le fait que le code est disponible et qu'on a commencé à releaser un module intéressant (en attendant la suite...).
Donc non seulement je ne suis pas d'accord avec toi, mais l'intérêt suscité par cette dépêche dans la communauté LinuxFR (108 commentaires en 1 jour 1/2, ca me parait pas mal du tout :) ) m'incitent à renouveler l'initiative lorsque nous annoncerons de nouveaux modules, en suivant la roadmap (http://www.nuxeo.org/sections/about/roadmap ), à commencer par Nuxeo Core et Nuxeo EP.
Merci à tous pour vos commentaires, et à certains pour votre soutien.
Amitiés à tous ceux qui me connaissent.
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Former des développeurs Python/Zope compétents
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 4.
Le deuxième obstacle c'est Zope: Zope 2 est en voie d'obsolescence, le futur c'est Zope 3. Ou pas. En l'état, l'état de l'art consiste à mélanger du Zope 2 et du Zope 3 en utilisant un "bridge" baptisé Five. Donc en terme de formation, un développeur pour bien maitriser la plateforme doit connaitre Zope 2, Zope 3 (qui n'a plus grand chose à voir avec Zope 2, c'est vraiment des concepts complètement différents) et Five (qui a ses propres spécificités). Et la ca devien t vraiment difficile de motiver les gens pour apprendre ces trois technos, sachant qu'il y en a deux qui seront bientôt obsolètes (ou pas).
Zope était le choix rationnel quand on voulait faire du Web en Python en 2000, maintenant il y a Django et Turbogears. La communauté Python est partagée sur ce sujet. C'est assez compliqué à expliquer quand on ne suit pas tout ca de près, mais bon l'impression générale c'est qu'on voit pas trop où ca va.
J'avais essayé de synthétiser la situation il y a 8 mois avec un schéma, maintenant c'est encore plus compliqué (et ca m'intéresse moins): http://blogs.nuxeo.com/sections/blogs/fermigier/2006_01_22_u(...)
A propos de Jython: Jython ( http://www.jython.org/ ) c'était une idée géniale en 2000, quelque chose de super prometteur, qui a été embarqué dans les 2-3 années qui ont suivi dans pas mal d'applications (libres et propriétaires, et oui!). Le problème, c'est que la version de 2006 n'a pas évolué (ou si peu) par rapport à la version de 2000. On est toujours bloqué à la version 2.1 de Python, alors que "CPython", l'implémentation "standard" vient de sortir en 2.5. Il y a donc des grosses différences entre les deux. Donc à l'heure actuelle plus grand monde ne s'intéresse à Jython, et il n'y a plus personne pour bosser dessus.
En l'état, on n'a pas encore choisi quel sera le langage de script de la plateforme Nuxeo 5. Mais rassure-toi, il y en aura un ! Pour l'instant on hésite encore entre JavaScript (et oui!), JRuby, Jython et Groovy. Le prérequis évident, c'est que le langage qu'on choisira devra tourner sur la JVM et s'interfacer avec Java conformément à la JSR 223 (http://jcp.org/en/jsr/detail?id=223).
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Bonne nouvelle ?
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 9.
"Java est tout sauf libre": je ne parle pas dans ma phrase de Java (relis ce que j'ai écris), mais des outils et des librairies libres. Je parle d'Eclipse, de Jackrabbit, de Lucene, de JBoss, de jPBM, etc. Alors ne me fais pas dire ce que je n'ai pas dit STP.
"Java est plus vendeur que Python": ben oui, c'est ca l'objet (outre les aspects technologiques) du changement. Ca correspond mieux aux schémas directeurs dans pas mal de boites ou de ministères. C'est plus facile à faire accepter dans les SSII. C'est plus facile à intégrer dans les SI. Y a plus de librairies libres disponibles. Etc. Faire le meilleur logiciel du monde, si personne ne l'utilise, ca ne sert à rien. Donc c'est important d'utiliser des technologies que les gens acceptent facilement.
"Après on mets ses convictions de côté": Avoir des convictions, c'est bien, mais il faut aussi qu'elles soient conformes à la réalité. Et la réalité change, alors les convictions doivent aussi s'adapter. Le choix de Zope était pertinent pour nous en 2000, il ne l'est plus en 2006.
"Je ne suis pas décideur": je suis sûr que tu prends des décisions, la preuve. Je suis désolé que notre nouvelle orientation ne te convienne pas, notre objectif est bien qu'il y a des développeurs qui soient convaincus de la pertinence de notre choix. Mais si ce n'est pas toi, il y en aura d'autres.
Donc sans rancune, et on se donne RDV quand on aura les première versions "montrables" (i.e. d'ici un mois).
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Bonne nouvelle ?
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 3.
"je pense que le consortium ObjectWeb pèse de tout son poids idéologique": je pense surtout que c'est "le marché" qui pèse en faveur de Java EE. Le consortium ObjecWeb participe à son niveau à l'écosystème Java libre, comme la Fondation Apache, la fondation Eclipse, JBoss, et bien d'autres, petits ou grands. Il s'agit d'un mouvement de fond, modelé par de nombreux acteurs, aussi bien côté vendeurs que côté utilisateurs, et dans lequel l'excellence technique est un facteur important, mais aussi la capacité à susciter l'adhésions des autres acteurs autour d'une technologie donnée.
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Bonne nouvelle :)
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 3.
Ta société = SCUB (http://www.scub.net) ?
Peut-être aura-t-on l'occasion de bosser ensemble un de ces jours ;)
S.
--
Stefane Fermigier, PDG, Nuxeo -- http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Bonne nouvelle ?
Posté par Stefane Fermigier (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 9.
Mais d'un autre côté, tu prends les choses un peu à l'envers:
1. Nuxeo cherche à recruter, parce que Nuxeo est une boite en croissance et que pour faire tous les projets qu'on a à faire (sans parler de tous ceux qu'on va arriver à vrendre plus facilement parce qu'on est passé à Java), on a besoin de développeurs.
2. Vu qu'on a changé de techno, autant que le profil du poste corresponde à ce que les gens vont faire une fois embauché: du Java, avec des outils et des librairies libres.
Maintenant, bien sûr qu'on a déja des compétences, vu la base de code qu'on a déjà écrite: http://svn.nuxeo.org/
Enfin, en ce qui concerne l'aspect commercial, ne t'inquiète pas: ce switch a été décidé en partie pour répondre aux attentes des clients et des partenaires.
S.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Poisson
Posté par Stefane Fermigier (site web personnel) . En réponse au journal Pierre Tramo a frappé !. Évalué à 1.
Maintenant on le fait en plein succès, avec des projets énormes en cours et des clients et partenaires qui nous suivent à 100%. Ou si on préfère, c'est en parlant à ces clients et partenaires qu'on est arrivé à cette idée de changement - après avoir été convaincus que techniquement on aurait uns solution non seulement qui tient la route, mais qui nous permet d'allier la souplesse de Zope avec la robustesse de Java EE tout en tirant parti de tous les composants libres de l'écosystème Java.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Et les clients actuels?
Posté par Stefane Fermigier (site web personnel) . En réponse au journal Pierre Tramo a frappé !. Évalué à 1.
Pour ce qui est de l'équipe, on est développeur avant tout, et probablement plus expert d'un domaine d'application (l'ECM) que d'un langage (Python vs. Java).
Mon témoignage personnel: j'ai découvert Java comme tout le monde en 1996, et Python quelques mois après. J'ai fait de Python mon langage de choix, et je me suis un peu investi dans sa promotion en France. Maintenant j'aime toujours Python (le langage) mais je constate que dans l'univers Java, il y a une pléthore (i.e. plus qu'en Python) de librairies libres utilisables et d'outils de développement qui rendent la vie du développeur plus facile. Ca évite d'avoir à "réinventer la roue" dans bien des domaines, ou utiliser des librairies à moitié finies.
Bref, il y a une place pour Python (ou Ruby, ou Groovy, ou d'autres langages de scripts) mais aussi pour un langage comme Java. L'idéal étant d'arriver à faire jouer les deux ensemble, ce qui est malheureusement suboptimal dans le cas de Python, dans la mesure où l'implémentation de Python pour la JVM, Jython (http://www.jython.org/), très novatrice à son époque (circa 2000), ne bouge plus depuis des années, et en est toujours à la version 2.1 des spécifications du langage alors que celui-ci vient tout juste de passer à la version 2.5.
--
Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/
"There's no such thing as can't. You always have a choice." - Ken Gor