Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par jmini

83PARTAGES

3  1 
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/

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de romaintaz
Rédacteur https://www.developpez.com
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.
2  0 
Avatar de eclesia
Rédacteur https://www.developpez.com
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 .
2  0 
Avatar de fregolo52
Expert confirmé https://www.developpez.com
Le 01/10/2012 à 12:58
Citation Envoyé par jmini Voir le message
On se retrouve donc avec deux projets proches, mais seulement partiellement compatibles.
On imagine pas la fondation Eclipse utiliser autre chose qu’Hudson. Reste à savoir si les deux projets Jenkins et Hudson pourront co-exister longtemps.
C'est exactement la même problématique qu'avec OpenOffice vs LibreOffice.
1  0 
Avatar de Teocali
Membre averti https://www.developpez.com
Le 01/10/2012 à 13:43
Je ne sais pas pour Hudson & Jenkins, mais pour LibrOffice/Open Office, le principal probleme vient d'un probleme de license, a ce que j'ai compris. la fusion de ces deux projets seraient difficile, non pas d'un point de vu technique, mais parce que leur license sont incompatible...
Mais bon, faudrait que je me penche un peu plus sur ce probleme
1  0 
Avatar de ValCapri
Membre régulier https://www.developpez.com
Le 01/10/2012 à 13:36
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.
0  0 
Avatar de jmini
Membre éprouvé https://www.developpez.com
Le 01/10/2012 à 13:41
Citation Envoyé par fregolo52 Voir le message
C'est exactement la même problématique qu'avec OpenOffice vs LibreOffice.
On est d'accord. C’est un beau gâchis d’énergie au final.

Je ne sais pas quels sont les soutiens pour Apache OpenOffice. Pour Eclipse Hudson, il y a quand même pas mal de boites derrière le projet à la fondation Eclipse (Oracle, Sonatype, Tasktop, WMWare…). S’ils arrivent vraiment à moderniser/standardiser le cœur d’Hudson, ça peut être très cool et faire une belle version 3.
Jenkins en tant que Version 2 +++ a également un bel avenir.

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.
0  0 
Avatar de Freem
Membre émérite https://www.developpez.com
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)
0  0 
Avatar de jmini
Membre éprouvé https://www.developpez.com
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.
0  0 
Avatar de Traroth2
Membre chevronné https://www.developpez.com
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.
0  0 
Avatar de Mickael_Istria
Membre émérite https://www.developpez.com
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.
0  0