La fondation Eclipse utilise Hudson pour construire les binaires de ses projets
Vers la fin de l'autre projet d'usine logicielle Jenkins ?

Les rubriques (actu, forums, tutos) de Développez
Réseaux sociaux


 Discussion forum

Sur le même sujet
Le , par jmini, Membre Expert
Suivant le principe «Eating your own dog food» (le fait d'utiliser ses propres produits afin d'en voir les qualités et les défauts [via Wikipedia]), la fondation Eclipse utilise la version 3.0.0-RC3 d’Hudson pour son instance sandbox.


La branche 3 d’Hudson désigne le développement de l’usine logicielle effectué dans le giron de la fondation Eclipse.

Pour mémoire, après le conflit qui avait opposé la communauté à Oracle, Oracle avait décidé de poursuivre le développement d’Hudson au sein de la fondation Eclipse.

La version 3.0.0 n’est pas encore officiellement sortie (la date évoquée est le 1er novembre). Il semblerait que la fondation Eclipse l’ait jugée suffisamment stable pour commencer à l’utiliser. (Il s’agit peut-être aussi de tester cette nouvelle version grandeur nature).

Une liste des nouveautés sera certainement publiée lors de la sortie officielle. Il ne faut cependant rien attendre de révolutionnaire.

Le gros du travail a consisté à nettoyer le code et les librairies qui n’étaient pas conformes en terme de propriété intellectuelle. Comme toutes les fondations de ce type, la fondation Eclipse dispose de règles strictes et d'outils pour garantir que le code hébergé répond à certains standards. Regroupées sous le terme d'IP Cleanliness (IP pour Intellectual Property), ces règles nécessitent par exemple d'éliminer toute dépendance à un projet sous licence LGPL qui n'est pas compatible avec la licence EPL (par exemple JFreeChart).

Depuis début 2011, le projet Jenkins a continué son évolution. Ce projet représente la suite naturelle de la branche 2.x d’Hudson. Il en a gardé son modèle de développement : des petites releases fréquentes (toutes les 1 à 2 semaines).

On se retrouve donc avec deux projets proches, mais seulement partiellement compatibles.

La vision d’Eclipse Hudson est de devenir un projet avec des processus de développement, de release plus structurés. L’architecture interne d’Hudson 3.x devrait d'ailleurs continuer à évoluer : certaines briques internes devraient être remplacées pour être plus proches des standards.

On imagine pas la fondation Eclipse utiliser autre chose qu’Hudson. Reste à savoir si les deux projets Jenkins et Hudson pourront co-exister longtemps.

https://hudson.eclipse.org/sandbox/


 Poster une réponse

Avatar de romaintaz romaintaz
Rédacteur/Modérateur
le 01/10/2012 14:25
Pour moi, le divorce Hudson / Jenkins est bel et bien consommé, et je les vois difficilement se réconcilier.
Certes Hudson a nettoyé son code, le rendant sans doute plus facile à évoluer... mais ce qui fait la force de ces serveurs d'intégration continue, c'est avant tout la communauté et les plugins. Et de ce côté-là, Jenkins a une avance phénoménale par rapport à son "ex", et la lourdeur des processus de la fondation Eclipse ne va certainement pas inciter les développeurs à revenir sur Hudson.
Avatar de Freem Freem
Expert Confirmé
le 01/10/2012 15:23
Citation Envoyé par jmini  Voir le message
Le gros du travail a consisté à nettoyer le code et les librairies qui n’étaient pas conformes en terme de propriété intellectuelle. Comme toutes les fondations de ce type, la fondation Eclipse dispose de règles strictes et d'outils pour garantir que le code hébergé répond à certains standards. Regroupées sous le terme d'IP Cleanliness (IP pour Intellectual Property), ces règles nécessitent par exemple d'éliminer toute dépendance à un projet sous licence LGPL qui n'est pas compatible avec la licence EPL (par exemple JFreeChart).

La (pauvre) présentation de EPL en français indique une incompatibilité avec la licence GNU GPL, mais pas avec GNU LGPL (que ce soit implicitement ou explicitement).
Serait-il possible d'avoir plus d'infos au sujet des différences? Parce que même si GPL et LGPL sont plutôt célèbres, je ne crois pas avoir souvent croisé la EPL? (Après, je suis peut-être le seul)

Citation Envoyé par jmini  Voir le message
Quant au changement de licence (EPL dépendance contrôlées et contre MIT + divers), je ne suis pas certain que cela intéresse les utilisateurs finaux.

Les utilisateurs finaux se moquent peut-être des licences utilisées en interne, mais il est bon de rappeler aux développeurs qu'il important de faire gaffe à ce qu'on utilise, je pense. Ca peut éviter pas mal d'emmerdes, après tout. Perso, j'aimerai pas recevoir un jour la visite de mon patron qui vienne me dire que je dois refaire du boulot déjà fait mais avec une autre lib car oracle à breveté l'API de la première, par exemple (bon, j'aurai pu utiliser apple aussi mais c'est plus sur le matos et l'esthétique eux)

Et pour Libre Office/Open Office, il semblerait que les bases de code diffèrent pas mal maintenant, vu que LO n'a pas eu la période de gel d'OOo. Bon, pas vérifié après, je ne fais que répéter quelque chose vu sur ce forum dans un post... (et j'ai pas le lien)
Avatar de jmini jmini
Membre Expert
le 01/10/2012 17:06
Citation Envoyé par Freem  Voir le message
La (pauvre) présentation de EPL en français indique une incompatibilité avec la licence GNU GPL, mais pas avec GNU LGPL (que ce soit implicitement ou explicitement).
Serait-il possible d'avoir plus d'infos au sujet des différences? Parce que même si GPL et LGPL sont plutôt célèbres, je ne crois pas avoir souvent croisé la EPL? (Après, je suis peut-être le seul)

La EPL == Eclipse Public License. Cette licence est utilisée principalement par la fondation Eclipse et l'écosystème autour d'Eclipse.

Ta question sur l’incompatibilité EPL <-> LGPL est très pertinente. Je n’en trouve pas de trace non plus dans la FAQ consacrée à EPL.

La Proposal d’Eclipse Hudson définit les Librairies sous LGPL comme un problème légal (nécessitant un remplacement). Pour JFreeChart c’est Eclipse BIRT qui a naturellement été utilisé.

Citation Envoyé par Freem  Voir le message
Et pour Libre Office/Open Office, il semblerait que les bases de code diffèrent pas mal maintenant, vu que LO n'a pas eu la période de gel d'OOo. Bon, pas vérifié après, je ne fais que répéter quelque chose vu sur ce forum dans un post... (et j'ai pas le lien)

Je pense qu'à terme, se sera également le cas pour Eclipse Hudson vs Jenkins. Eclipse Hudson se veut la version 3 d'Hudson.

Citation Envoyé par romaintaz  Voir le message
Pour moi, le divorce Hudson / Jenkins est bel et bien consommé, et je les vois difficilement se réconcilier.
Certes Hudson a nettoyé son code, le rendant sans doute plus facile à évoluer... mais ce qui fait la force de ces serveurs d'intégration continue, c'est avant tout la communauté et les plugins. Et de ce côté-là, Jenkins a une avance phénoménale par rapport à son "ex", et la lourdeur des processus de la fondation Eclipse ne va certainement pas inciter les développeurs à revenir sur Hudson.

Les Plugin Eclipse Hudson ne doivent pas forcément respecter la licence EPL. À partir du moment où ils sont installé séparément...

Je suis d'accord avec toi, pour qu'Eclipse Hudson gagne, il faut que le retour sur investissement (en terme de nettoyage de code), se traduise par un développement plus simple pour les plugins. Sinon c’est fichu pour Hudson.

La plus grosse communauté est du côté de Jenkins (~= Hudson 2.x). Et c'est un avantage non négligeable.
Avatar de eclesia eclesia
Rédacteur
le 01/10/2012 19:41
On utilise Jenkins dans notre boite, et on le recontre souvent en dehors aussi.Il couvre bien nos besoins, combiné avec des scripts ant on arrive a faire ce qu'on veut.

Je ne vois pas pourquoi le choix d'eclipse d'avoir changer le numero de version a 3 alors que ce n'est qu'une 2.x 'nettoyée' va changer la donne, en tout cas j'espere que les gens seront plus intelligent que ca.

bref, ca serait bien d'etre un peu moins pro-eclipse dans le titre des news. restons objectifs on ne fait pas encore partie des journaux a scandales .
Avatar de Traroth2 Traroth2
Expert Confirmé Sénior
le 02/10/2012 10:36
Citation Envoyé par ValCapri  Voir le message
Oui, en effet, il serait cool que les développeurs Jenkins rejoigne le projet Hudson à partir de la version 3.0. Quitte à faire "2" versions, une version "non stable" releasé 1 à 2 semaines (genre de milestone comme pour Eclipse) et une stable releasé quand elle est prête.

Surtout que la guerre avec Oracle pour OpenOffice et Hudson n'ont plus beaucoup de sens, vu qu'ils ont été donné à des fondations (Apache et Eclipse). Ils seront bon de travailler sur une fusion, car ça me donne l'impression qu'il y a de l'énergie gâchée.

Le seul "hic" avec Oracle reste Solaris et MySQL qui n'ont plus vraiment le caractère Open Source qu'ils avaient avant. Je vois mal MariaDB, Percona et MySQL fusionnés.

OpenOffice est sous licence ASL 2.0 alors que LibreOffice est en LGPL. Une fusion est donc possible uniquement si Apache renonce à développer OpenOffice, puisque le code résultant ne pourra être que sous LGPL (en fait, comme OpenOffice était initialement sous LGPL, je me pose des questions sur la légalité du passage sous ASL. Tous les contributeurs étaient-ils d'accord ?).

Jenkins est sous licence MIT, donc il n'y a pas du tout le même genre de problème. On peut parfaitement intégrer du code sous licence MIT dans un logiciel sous EPL.
Avatar de Mickael_Istria Mickael_Istria
Membre Expert
le 02/10/2012 11:12
Niveau soutien a Hudson, c'est quand meme assez faible: Oracle, un contributeur d'une boite de service danoise, et c'est a peu pres tout! http://www.eclipse.org/projects/proj...hnology.hudson

La plupart des autres grosses boites membres de la fondation Eclipse utllisent Jenkins plutot qu'Hudson, tout simplement parce que le projet continue a evoluer plus vite. Il y a CloudBees derriere Jenkins, et CloudBees commence a etre une pointure. Ils ont pleinement la meme capacite (voire plus) a maintenir Jenkins qu'Oracte a maintenir Hudson.

Jenkins s'est empare de toute la communaute, ce qui lui met beaucoup d'avance sur Hudson. De plus, il y a de tres tres grosses installations de Jenkins un peu partout dans le monde, et Hudson n'a a ma connaissance pas de telle use-case. On a moins de souci sur le Jenkins chez JBoss (avec son bon millier de jobs et sa cinquantaine de slaves sur tous les OS) que la Fondation Eclipse n'en a avec Hudson pour une centaine de job et 13 slaves...

La Fondation garde Hudson parce qu'il est dans la Fondation, et non pas parce qu'il est mieux que Jenkins.
Jenkins n'a vraiment aucun souci a se faire je pense.
Avatar de jmini jmini
Membre Expert
le 02/10/2012 11:22
Citation Envoyé par eclesia  Voir le message
bref, ca serait bien d'etre un peu moins pro-eclipse dans le titre des news. restons objectifs on ne fait pas encore partie des journaux a scandales .

Entièrement d'accord avec toi... Je signale que le titre n'est pas de moi. J'avais mis quelque chose de plus factuel (et de moins polémique).

Citation Envoyé par eclesia  Voir le message
Je ne vois pas pourquoi le choix d'eclipse d'avoir changer le numero de version a 3 alors que ce n'est qu'une 2.x 'nettoyée' va changer la donne, en tout cas j'espere que les gens seront plus intelligent que ca.

Pour moi le changement de numéro de version a du sens: la retro compatibilité a été cassé dans certain domaine, la documentation, le bugtracker ne sont plus au même endroit, la licence change...

Du point de vu utilisateur, il n'y a vraisemblablement pas grand-chose.

On se retrouve plutôt avec un problème de lisibilité:
=> Jenkins 2.x est à mon avis plus avancé sur certains points que Hudson 3.x.

Citation Envoyé par Traroth2  Voir le message
Jenkins est sous licence MIT, donc il n'y a pas du tout le même genre de problème. On peut parfaitement intégrer du code sous licence MIT dans un logiciel sous EPL.

A mon avis l'incompatibilité vient plutôt de toutes les modifications qui ont été faites au cœur d'Hudson.
Avatar de Freem Freem
Expert Confirmé
le 02/10/2012 11:45
Citation Envoyé par eclesia  Voir le message
bref, ca serait bien d'etre un peu moins pro-eclipse dans le titre des news. restons objectifs on ne fait pas encore partie des journaux a scandales .

Pas encore, en effet
Avatar de air-dex air-dex
Membre Expert
le 03/10/2012 3:09
Si Jenkins à une communauté, et il me semble que c'est le cas, cette dernière adaptera les solutions de Hudson pour Jenkins ou trouvera des alternatives pour Jenkins. Pas de soucis de ce côté là.
Avatar de jmini jmini
Membre Expert
le 03/10/2012 7:54
Citation Envoyé par air-dex  Voir le message
Si Jenkins à une communauté, et il me semble que c'est le cas, cette dernière adaptera les solutions de Hudson pour Jenkins ou trouvera des alternatives pour Jenkins. Pas de soucis de ce côté là.

C'est dans l'hypothèse ou Hudson reprend la main ou l'avantage de l'innovation sur Jenkins. Pas certain que ce soit le cas pour le moment...
Avatar de Traroth2 Traroth2
Expert Confirmé Sénior
le 03/10/2012 12:50
Citation Envoyé par jmini  Voir le message
A mon avis l'incompatibilité vient plutôt de toutes les modifications qui ont été faites au cœur d'Hudson.

Ah ça, c'est parfaitement possible...
Offres d'emploi IT
Développeur Fullstack JS/RUBY – Pureplayer rattaché à un grand groupe français
CDI
Mobiskill - Ile de France - Paris (75000)
Parue le 20/03/2014
Ingénieur développement JAVA/JEE
CDI Freelance
Agilitech - Provence Alpes Côte d'Azur - Sophia-Antipolis
Parue le 27/03/2014
Ingénieur Système Microsoft - H/F
CDI
CetSI - Ile de France - Nanterre (92000)
Parue le 02/04/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula