Publicité
+ Répondre à la discussion Actualité déjà publiée
Affichage des résultats 1 à 16 sur 16
  1. #1
    Membre Expert

    Inscrit en
    janvier 2009
    Messages
    464
    Détails du profil
    Informations forums :
    Inscription : janvier 2009
    Messages : 464
    Points : 1 178
    Points
    1 178

    Par défaut La fondation Eclipse utilise Hudson, vers la fin de Jenkins ?

    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/

  2. #2
    Expert Confirmé Sénior Avatar de fregolo52
    Homme Profil pro
    Développeur C
    Inscrit en
    août 2004
    Messages
    2 315
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur C

    Informations forums :
    Inscription : août 2004
    Messages : 2 315
    Points : 4 995
    Points
    4 995

    Par défaut

    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.

  3. #3
    Membre régulier Avatar de ValCapri
    Homme Profil pro Lionel Schinckus
    En formation chez Technifutur pour me spécialisé dans le dev mobile
    Inscrit en
    mars 2010
    Messages
    43
    Détails du profil
    Informations personnelles :
    Nom : Homme Lionel Schinckus
    Âge : 24
    Localisation : Belgique

    Informations professionnelles :
    Activité : En formation chez Technifutur pour me spécialisé dans le dev mobile

    Informations forums :
    Inscription : mars 2010
    Messages : 43
    Points : 75
    Points
    75

    Par défaut

    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.

  4. #4
    Membre Expert

    Inscrit en
    janvier 2009
    Messages
    464
    Détails du profil
    Informations forums :
    Inscription : janvier 2009
    Messages : 464
    Points : 1 178
    Points
    1 178

    Par défaut

    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.

  5. #5
    Membre confirmé
    Inscrit en
    novembre 2004
    Messages
    129
    Détails du profil
    Informations personnelles :
    Âge : 33

    Informations forums :
    Inscription : novembre 2004
    Messages : 129
    Points : 299
    Points
    299

    Par défaut

    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

  6. #6
    Rédacteur/Modérateur
    Avatar de romaintaz
    Homme Profil pro Romain Linsolas
    Java craftsman
    Inscrit en
    juillet 2005
    Messages
    3 747
    Détails du profil
    Informations personnelles :
    Nom : Homme Romain Linsolas
    Âge : 36
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2005
    Messages : 3 747
    Points : 7 204
    Points
    7 204

    Par défaut

    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.
    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

  7. #7
    Expert Confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2008
    Messages
    805
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2008
    Messages : 805
    Points : 2 650
    Points
    2 650

    Par défaut

    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)

  8. #8
    Membre Expert

    Inscrit en
    janvier 2009
    Messages
    464
    Détails du profil
    Informations forums :
    Inscription : janvier 2009
    Messages : 464
    Points : 1 178
    Points
    1 178

    Par défaut

    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.

  9. #9
    Rédacteur
    Avatar de eclesia
    Inscrit en
    décembre 2006
    Messages
    1 976
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 1 976
    Points : 2 779
    Points
    2 779

    Par défaut

    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 .

  10. #10
    Expert Confirmé Sénior

    Inscrit en
    décembre 2003
    Messages
    2 814
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 2 814
    Points : 6 802
    Points
    6 802

    Par défaut

    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.
    Les brevets ? Le type qui a inventé l'eau chaude doit être grave blindé de thunes !

  11. #11
    Membre Expert
    Avatar de Mickael_Istria
    Homme Profil pro Mickael Istria
    Développeur Expert Eclipse RCP
    Inscrit en
    juillet 2008
    Messages
    684
    Détails du profil
    Informations personnelles :
    Nom : Homme Mickael Istria
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Expert Eclipse RCP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2008
    Messages : 684
    Points : 1 282
    Points
    1 282

    Par défaut

    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.
    Tu fais du JEE/Web/Mobile dans Eclipse? T'as essaye JBoss Tools ?
    Read my blog about Eclipse | Follow me on twitter

  12. #12
    Membre Expert

    Inscrit en
    janvier 2009
    Messages
    464
    Détails du profil
    Informations forums :
    Inscription : janvier 2009
    Messages : 464
    Points : 1 178
    Points
    1 178

    Par défaut

    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.

  13. #13
    Expert Confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2008
    Messages
    805
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2008
    Messages : 805
    Points : 2 650
    Points
    2 650

    Par défaut

    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

  14. #14
    Membre Expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    août 2010
    Messages
    1 081
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France

    Informations forums :
    Inscription : août 2010
    Messages : 1 081
    Points : 2 229
    Points
    2 229

    Par défaut

    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à.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  15. #15
    Membre Expert

    Inscrit en
    janvier 2009
    Messages
    464
    Détails du profil
    Informations forums :
    Inscription : janvier 2009
    Messages : 464
    Points : 1 178
    Points
    1 178

    Par défaut

    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...

  16. #16
    Expert Confirmé Sénior

    Inscrit en
    décembre 2003
    Messages
    2 814
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 2 814
    Points : 6 802
    Points
    6 802

    Par défaut

    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...
    Les brevets ? Le type qui a inventé l'eau chaude doit être grave blindé de thunes !

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •